Hi, all,
(Well, former message had a typing error in it's title as you must have noticed - which shows what quirks might occur when being eager to speed things up ;-)
There's more space for speed/efficiency improvements.
The second issue (I thank my friend Dvae who pointed similar issue years ago) is reading of input files.
When done with open(2)/read(2) interface, it's correct, but mapping it into memory with mmap(2) is only slightly different, but much more efficient. This is because kernel does things for you.
I can't give you a direct estimation about how switch to mmap(2) interface would speed-up GPC, but I remember an application (oops, I forgot to add it to my CV) when we had to read complete registry of Croatian companies in order to do a search. In this simplistic case with one big file, mmap(2)-ing it instead of open(2)/read(2)-ing it has shown _50%_drop!!!!_ in use of 'system time'. 'User time' also dropped, because interface routines didn't have to copy records to memory locations allocated with malloc - they were already mmap(2)-ed in, I only needed to re-link pointers to them.
Off course, several routines had to be modified to be read-only to avoid copy-on-write overhead over input file, and to remove dependencies from '\0' trailing byte. At the time, it seemed as an acceptable price.
I can't estimate the amount fo work required to attempt to implement mmap(2) interface to read files (on platforms where available) seemlesly. But from 'Internals', since parser calls lexer, mostly only lexer would have to be modified - and have two versions (one for platforms with MMAP and one for others, selected etiher with -DUSE_MMAP compile directive when compiling GPC, or even at runtime).
The change would, however, significantly decrease copying overhead when dealing with large files. Also this could be applied to generating GPI files, but that area I'm not certain about yet.
Please give your valuable opinions - thanks, Mirsad
-- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.