On Tue, Mar 26, 2013 at 5:08 PM, Mikael Morin <mikael.mo...@sfr.fr> wrote: > Le 24/03/2013 22:58, Janne Blomqvist a écrit : >> The attached patch takes the crude approach of first sequentially >> reading the .mod file into a temporary buffer, then does the actual >> parsing from that buffer. >> > I don't like it much, but knowing how bad module files are currently > handled, it's probably the way to go.
I don't like it either, I'd have preferred that my previous efforts to
parse module files sequentially without the tmp buffer would have been
successful. But alas, this is better than what we have now, IMHO.
>> - Caching module files, a crude implementation of the old "module
>> namespaces" idea. E.g. put the uncompressed module contents into a map
>> keyed by module name. (part 3/3).
>>
> But I'm not too fond of that one. Bah, let's see if it improves things.
As of today, I don't think this is useful. But on top of the zlib
patch it would reduce the decompression overhead when the same module
is used repeatedly in the same translation unit. Whether the zlib
overhead is significant enough to be worth bothering about I don't
know; I'm happy to take a wait-and-see approach wrt this.
>> @@ -1004,7 +1008,7 @@ static void bad_module (const char *)
>> ATTRIBUTE_NORETURN;
>> static void
>> bad_module (const char *msgid)
>> {
>> - fclose (module_fp);
>> + XDELETEVEC (module_content);
>>
> I know this is followed by fatal errors only, but I would feel much
> better with an additional 'module_content = NULL;'
>
> OK with that change.
Done. Joost also reported that my original patch didn't pass bootstrap
(I cheated and used --disable-bootstrap). Slightly fixed patch
attached, and committed as r197124.
--
Janne Blomqvist
tmpbuf.diff
Description: Binary data
