Loaded 50 URLs the link. nsDNSLookup::Create was tracked by SpaceTrace as allocating 139 different 1104 byte objects on Linux, 153456 bytes. At a point 30% through the run, 30 different nsDNSLookup objects were in memory, totalling 33120 in size. At a point 70% through the run, 32 different nsDNSLookup objects were in memory, totalling 35328 in size. This appears to be a pretty constant drain on the footprint. Suggesting that a way be found to reduce the cached lookup object size, not suggesting that we do not cache lookups. Things like: we should not track the expiriation time as an int64, but could find a smaller representation to expire them out on (int16, and if you reach the max number of seconds, then we'll simply have to do the lookup again).

neeti, can you take a look at this footprint issue, and assign to an appropriate milestone? thx!

cc'ing Gordon

Changing mExpires to 16 bits will save about 90 bytes. I'm not sure, but we might chew up more memory adding code to convert to and from PRTime values. Most of the space comes from from the PRHostEnt and the recommended buffer size. We could add code to copy the lookup results into a more compact form, but that will introduce a few extra mallocs per lookup. Right now, if a lookup expires, we resuse the structure to update it, avoiding any malloc. If it were in a more compact form, we would need to malloc a buffer of the default size and then another buffer of the compact size.

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

With recent changes in nsSocketTransport, we may just get rid of the DNS cache, which makes this bug very low priority and possibly a candidate for WONTFIX.

hey gordon, is there a bug for getting rid of DNS cache?

No because we don't know if that's what we want to do yet.

is this bug still valid since DNS rewrite in bug 205726 (eventhough the patch didn't show nsDNSLookup) ?

olivier: yes and no. while the class nsDNSLookup no longer exists, we are still caching equivalently sized buffers. however, the buffers would now show up as being allocated by LIBC (struct addrinfo) or NSPR (struct PRHostEnt). storing these structures in a more compact form is probably not worth the effort. i don't think the footprint savings will be worth the extra code. marking WONTFIX for the record, w.r.t. comment #5: the socket transport is no longer caching DNS lookups. we need the DNS cache.

VERIFED/wontfix.