GNOME Bugzilla – Bug 169792
let GScanner mmap() files
Last modified: 2005-03-15 16:28:40 UTC
Since using mmap seems to be en vogue at the moment and I wanted to see if it makes a difference, I changed libgimpconfig/gimpscanner.c so it transparently tries to use mmap() to read the file. Seems to work fine but it also doesn't seem to make any measureable (or let alone noticeable) difference. I had a look at the libgsf implementation of this and my implementation should be as portable, even includes the code for Win32. However since it deosn't seem to make any difference, I wonder if we should add this to CVS at all. It only makes the code more difficult to maintain.
Created attachment 38484 [details] [review] let GimpScanner mmap() files if possible
If anyone wants to give this a try, perhaps on Win32, uncomment GIMP_SCANNER_PROFILE to get some basic profiling data.
Our config files are so tiny, this shouldn't make any difference. I'd vote for code simplicity.
pluginrc easily becomes 400kB; not exactly what I'd call tiny. But then we aren't copying this into memory. The only thing that this patch changes is that GScanner doesn't need to allocate a read buffer of 4kB and can save a few calls to read(). I think it would make sense to use mmap() here if GLib provided an abstraction layer for it so that we wouldn't have to deal with the portability issues.
It appears that this request doesn't make much sense in GIMP. If at all then it is GScanner that should be using mmap(). I'll reassign this report to GLib and attach a patch for GScanner.
Created attachment 38519 [details] [review] patch that makes GScanner mmap the input file if possible
The patch is somewhat hackish (it uses a magic value for the file descriptor and abuses scanner->buffer to store the mmap'ed address). It might even break apps that access the "private" input_fd field in the GScanner struct.
May affect bug 165693
Is gscanner doing a one time read of the file (ie, reading it from start to finish). If so, it is probably inefficient to use mmap here. mmap only makes sense for long term usages of a file.
Usually, a user of GScanner will read the file from start to end. The only advantage of using mmap here is to avoid allocating 4kB for the scanner's buffer (and copying the data through this buffer).
The thing to be optimized here is probably the generation of a 400K rc file in the first place...
I don't think the GIMP pluginrc is a considerably weak spot. Caching this data in an rc file tremendously cuts down startup time. But this is somewhat unrelated here. As reported on the gtk mailing-list, people are using GScanner to implement XML parsers and read files that are a lot larger than this one. But feel free to close this bug as WONTFIX. It was just an experiment I did and I wanted to stick the patch somewhere. Since it doesn't seem to make much of a difference anyway, I fully understand if you don't consider it useful.
imho, this is a wontfix. aobut the 4 kb buffer: just alloca it.
Am playing around ignore this
x