On Wed, May 21, 2003 at 01:39:41PM -0400, Dan Merillat wrote:
> On Mon, 19 May 2003, Toad wrote:
>
> >
> > 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.
>
> Then I humbly suggest only adjusting it o
On Wed, 21 May 2003, Toad wrote:
> On Wed, May 21, 2003 at 01:39:41PM -0400, Dan Merillat wrote:
> > On Mon, 19 May 2003, Toad wrote:
> >
> > >
> > > 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.
On Mon, 19 May 2003, Toad wrote:
>
> 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.
Then I humbly suggest only adjusting it on file open and close rather then every
read. This also saves us a ton of L
>>NativeFSDir level because it might interfere with CircularBuffer
>>implementation. In CVS unstable branch, please update and try again.
>
>Good, I will do a shot on it as soon a possible to see if I can provide
any hard numbers on the exact performance gain.
No hard numbers but a couple of scre
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 spe
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 met
>>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
>Hrmm. This should usually b
>> 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
>> Setup:
>> 1. Firewalled v6032 node (not transient but not able to recieve
>> incoming connections)
>If it cannot receive incoming connections it should be set transient.
True, it was an accident which I discovered halfway through the profiling.
This might be a good time to start a discussion
On Fri, May 16, 2003 at 07:31:33PM +0200, Niklas Bergh wrote:
> Damn, I sent this mail to myself instead of to devl.. Another try then..
> sorry for loosing the formatting.
>
> The attachements I am talking about can be retrieved from
> http://194.236.28.174/freenetstuff/prof.zip
>
> /N
>
>
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
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
Hrmm. This should usually be pret
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
Damn, I sent this mail to myself instead of to devl.. Another try then..
sorry for loosing the formatting.
The attachements I am talking about can be retrieved from
http://194.236.28.174/freenetstuff/prof.zip
/N
- Original Message -
From: "Niklas Bergh"
To:
Sent: Friday, May 16, 2003 5
14 matches
Mail list logo