http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|pault at gcc dot gnu.org |jvdelisle at gcc dot
| |gnu.org
--- Comment #16 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-10
17:47:07 UTC ---
Paul, taking this one if you do not mind.
I have run some tests. I replaced the long strings in the various minit
invocations with a 2 or 3 character mnemonic. For a particularly large module
the size of the .mod file created is:
un-patched -> 8210691 bytes
gzipped -> 724854 bytes
patched -> 6280606 bytes
patched and zipped -> 714777 bytes
Compressing the file is quite good. There is no particular advantage to
changing the minit strings if one is going to compress the file. The question
is then what cost in time do we have of actually compressing and decompressing.
The above just deals with raw file size and I think compression is a good idea.
If we leave the strings alone, we could allow manual decompressing the files
to look at them for debugging purposes.
The next thing I would like to consider is some sort of module caching. Let's
say we create a module namespace for each module file. I would suggest
allowing a fixed number of these to conserve memory usage. Modules that are
USEed repeatedly would be retained, free up ones not used if more are needed.
I am thinking of some sort of leased recently used scheme.
Another thing I wonder about is how efficiently do we retrieve from this name
space. (I have more to study on the internals of module.c)
