On Mon, May 19, 2003 at 03:52:39PM -0400, Dan Merillat wrote: > On Sat, 17 May 2003, Toad wrote: > > > On Sat, May 17, 2003 at 02:05:44PM +0200, Niklas Bergh wrote: > > > Well, I guess I just have to start the discussion myself then :).. > > > > > > According to the profiler 30% of the CPU is spent in > > > NativeFSDirectory$NativeBuffer.setLastModified.. Well.. this method would > > > seem to be called close to once for every single byte read from the > > > datastorage. That method is called 2.5 million times, about samt number of > > > times that NativeInputStream.read is called and pretty close to the amount > > > of data that I was requesting from the node (2.5 megs). See the attached > > > HTML if you want to study an example of this situation yourself (just > > > expand > > > the tree until you encounder the invalid percentages and then continue > > > expanding). > > > > Okay, the problem seems to be single byte reads from the datastore, > > which happen when reading fields. This can be corrected by adding a > > BufferedInputStream with a relatively small buffer (I'm using 8kB), in > > FSDataStoreElement.KeyInputStream. We do NOT add a buffer at the > > NativeFSDir level because it might interfere with CircularBuffer > > implementation. In CVS unstable branch, please update and try again. > > Why are we setting lastmodified every read() call anyway? Each read > will cause the lastaccess time to be updated. Is this extra overhead > added for windows?
Because we do not have access to the lastaccess time in java. And also because we need to keep the in-memory LRU consistent and up to date. > > --Dan > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20030519/99e506d7/attachment.pgp>
