110169 - footprint: nsDNSLookup objects cost 1104 bytes each

Status: VERIFIED WONTFIX

(Core :: Networking, defect, P4)

Description

[Garrett Arch Blythe]

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).

Comment 1

[Cathleen]

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

Comment 2

[neeti]

cc'ing Gordon

Comment 3

[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.

Comment 4

[scottputterman]

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 [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 5

[gordon]

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.

Comment 6

[Cathleen]

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

Comment 7

[gordon]

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

Comment 8

[Olivier Cahagne]

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

Comment 9

[Darin Fisher]

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.

Comment 10

[benc]

VERIFED/wontfix.