Larry Jones wrote: >Maybe in the sense that if it were worth doing, malloc() should do it. >So if malloc() doesn't do it, it's probably not worth doing. > >
Okay, I'm not against this in principle, but before I make the change, I'm going to wrap my nightly tests with a call to "time" so we can spot any major slowdowns. It may be a few days. >>I gather that some systems don't automatically >>align large malloc requests, or this GNULIB module probably would not >>exist. >> >> > >According to the comments in the module, you're the author! It would >seem that it was written specifically for CVS as a replacement for >valloc(). > > I did recall that, though I did have help from the GNULIB folks. There are one or two people there who probably would have stopped me and told me the module was unnecessary if they thought it was. :) I had also thought that there had been some bug reports from others, meaning others had found a use for it, but glancing at the log messages for pagealign_alloc.c, it appears that only a general GNULIB standard compliance change & a rewrite of the FSF address in the license notice have been made since the original changes Bruno & I came up with. >A much more effective optimization would be to enhance the buffer system >so that you could simply hand-off the original (non-page aligned!) big >buffer to it rather than having to copy all the data. > > Hrm. What big buffers get copied? On the server, it looks to me like buf_read_file already reads data directly into buffer_datas. Then those are moved directly into the buffer which outputs to the network. Ah, the client does appear to behave as you say. send_modified should probably use buf_read_file too - this would fix half the problem. Do you know if mmap on any systems actually use the mapped file as the swap file for mapped memory? If so, then having buf_read_file mmap a file rather than copying it into buffer_datas might allow the file to be read piecemeal just as it is written, and nothing would be copied to disk when portions of the buffer_data created this way were "swapped out". i.e. a file might not ever be held in memory all at once, without any complex tracking on our part. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot <http://ximbiot.com> v: +1 717.579.6168 f: +1 717.234.3125 <mailto:[EMAIL PROTECTED]> _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
