Derek Price writes: > > 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 was thinking along the same lines, but most of the nightly tests don't deal with large files, so I'm not sure that's a valid test. It might be better to time just the compression test that does use a large file rather than the entire suite. > the client does appear to behave as you say. send_modified should > probably use buf_read_file too - this would fix half the problem. Yes, I seem to remember a bug report where one system objected to the ridiculously big read send_modified tries to do. But buf_read_file() may require some changes -- it looks like buf_read_file expects the exact file size as an input and the client doesn't necessarily know the exact size, only an upper bound. > 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. That would only work for binary files -- for text files, we need stdio to do line ending conversions. -Larry Jones I think if Santa is going to judge my behavior over the last year, I ought to be entitled to legal representation. -- Calvin _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
