bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.
Darin sez: "nsNetUtil.h (chalk full of inline functions) results in a lot of duplicate code throughout the product. making this into a shared library will help reduce code size." This is a good idea. No sense in having all these inline functions duplicated 5 times in a module when you could just be linking against a static or dynamic library for them. So I guess the question is, static or dynamic? I'm leaning towards static because that means we don't have runtime link dependencies, something we've always worked to avoid in our codebase. I think I'll start with static and see what kind of footprint increase/decrease I see.
Status: NEW → ASSIGNED
Priority: -- → P2
Hardware: PC → All
Target Milestone: --- → mozilla1.2beta
adding footprint, accepting, and adding priority
alec: i just checked in an initial version of this library. there's a list of todo items at the top of the source file, repeated here: // - prune out unnecessary header files // - add xpcom-shutdown observer / cleanup gIOS foo // - possibly cache other xpcom factories // - is this a shared or static lib? // - add any other inline functions declared in necko IDL files (e.g., // nsIFileStreams.idl)
I'd be surprised if the linker didn't merge all the non-inlined versions within a single module. In theory, the inlined versions should provide better peformance, so as well as looking at footprint, you should look at perf. Not sure if that all happens on the old egcs compiler we use, though.
ok, I've spent a little time poking at this, and so far I'm seeing no footprint improvement. The libraries I've looked at so far: i18n.dll (112k), gkparser.dll (212k), necko.dll (396k) I'm trying gkcontent now. However, I'm not giving up, because I think there could be a minor performance advantage to caching the IO service.. and if there are any consumers that cache their own io service reference, then we might see a footprint reduction.
argh, no change even in gkcontent.dll (1420k) oh well. I'm going to move this bug out then, because its a lot of work for very little gain.
Target Milestone: mozilla1.2beta → mozilla1.3alpha
oh, I should add that I have not explored the dynamic version of this library, but I suspect that it would take quite a bit for the gain from moving these small functions into a DLL to outweigh the cost of having to import these functions. (because importing one function from another DLL is not as simple as just calling it - there's overhead in calling across dll boundaries due to address adjustment, etc - its similar to the overhead of calling a virtual function)
oh, well... thanks for investigating this!
marking WONTFIX for now, since there doesn't seem to be any great benefit :(
oops, actually marking WONTFIX
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
VERIFIED, per eng.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.