>>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 pretty fast. Are you sure it's not >profiler overhead? There are five modes of profiling, with different levels of overhead, available to me using this profiler: 0. No profiler interaction what so ever 1. Code instrumented but not collecting data 2. Code instrumented and collecting data using snapshoting 3. Code instrumented and collecting data using System.getCurrentMillis() on function enter and exit 4. Code instrumented and collecting data using getCurrentThreadCpuTime() on function enter and exit Mode 0: Is exactly the same as what a production class node is running, no profiling possible and no overhead added anywhere Mode 1: Imposes a slight overhead during class loading but since this is done only once for each class this overhead is totally neglible. Further on this mode adds a slight penality to each function call (it adds another two function calls doing nothing to each source function call). According to the profiler-author this mode should only add a slight overhead to the running application. This is the mode I used for 'run 1' to 'run 4' Mode 2: I have never tried this mode but I think that what it does is to periodically freeze the JVM and take a snapshot of where all threads are located. This method of course is inaccurate when running short-duration profiling sessions but I am starting to think that it might be very useful for running multi-day profiling sessions.. This method should only add slightly more overhead than Mode 1. Mode 3: Whenever an instrumented method is called and leaved the profiling code will register the current time using a call to System.getCurrentMillis() and using the result from that call to register the amount of time spent inside that method. Again, this method adds a bit more overhead, than the previous mode, to the running application. This method was what I was using during 'run 5' to collect profiling data. Mode 4: As mode 5, except that instead of calling System.getCurrentMillis() the profiler will call getCurrentThreadCpuTime() and register the call times aquired on a thread-basis. If one is interested in seeing what the different threads are doing then this is the only mode that will provide correct data. As with all previous modes this method is a bit more expensive than the previous one. Mode 1-4 apparently all becomes more expensive when the source contains many small functions. In order to avoid much of this extra overhead you can configure the profiler not to instrument any methods below a certain size (the touch() method I talked about in another mail is such a one for instance). In my testing I had set this size threshold to 250 bytes which is a rather large value I am not totally sure about the exact amount of overhead added by each level but according the the author the step from Mode 0 to Mode 1 should impose no more that a 30% penality (shaving about 200MHz of the CPU I ran the test on then). Since I used a very restrictive method size threshold I assume that the instrumented code should impose a maximum of those 30% overhead. Another thing worth mentioning is that when profiling measurement of time consumed in functions might be off the real value by a factor of 10 (or 100 or 2) or so. Invocation count and time spent in functions relatively to each other usually provide the best insights. >Oh, and what is the origin of the profile data (busy node?). Nope, it was the non-transient node that couldn't recieve incoming connections. The node was doing nothing else than serving my spiders. /N _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
