-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, July 22, 2003, at 08:36 AM, Skip Montanaro wrote: > It looks like the Mac OS X implementation of getaddrinfo is just dog > slow. > I instrumented setipaddr with calls to gettimeofday() to see how long > different sections took. It turns out that getaddrinfo() is hideously > slow: This would be hideously slow by design - Python is sitting idle while the lookupd directory is queried (you can tell as lookupd process is chewing CPU). I don't think this should affect an Apple release - Python 2.2.0 as shipped with OS X 10.2 has the same behavior. > when you get into setipaddr() name[0] will always be '\0' and so > you'll take > the first branch. Do you need all of getaddrinfo()'s bells and > whistles to > properly set up addr_ret in this case? At worst, can't the > getaddrinfo() > call be made once and then cached? 'man lookupd' says 'lookupd keeps a cache of recently located items to improve system performance', so Python shouldn't have to (?) I've found no way of determining what queries are being sent to lookupd :-( - -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE/HJosh8iUz1x5geARAsDuAJ0fogD1PAqmm79skBYHgVfpc6Y51ACfdqwR VUaMwjBGDPSMjXUaX1bb+kI= =NrnR -----END PGP SIGNATURE-----
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4