Re: profiling aufs

On Mon, 2002-10-07 at 21:15, Andres Kroonmaa wrote:
> The only thing we'll add to our knowledge is time between aio
> completion and its noticing in main thread. To test that we
> could compile special squid with only 1 worker thread and use
> dedicated PROF timers for thread, with unaccounted time disabled.
> If you really suspect code path to suck, this test can be done.

I don't think we need to just yet. As we both said, aio service time can
be measured outside the profiling framework.

> If we use threads only for something timeconsuming, then why we
> need tick precision? If we want to profile timeconsuming thing
> itself, then maybe it makes sense to support both threaded model
> and unthreaded, then we can easily profile the thing when unthreaded.

Uhmm yes. If you reread my email I suggested compile time enabled of
threaded and non threaded profiling. Supporting non threaded 'thing' is
not always sane, whereas supporting threaded profiling is.
 
> Or, create special threaded version of profiler calls that have any
> required overhead and are specifically compiled with debug option.
> For main squid I'd rather like to optimise existing profiling to
> the point that it has least possible overhead in all cases.
> This is crucial for stuff that gets run over 100K times/second.

Yep. No argument here.
 
> PS. I don't really object doing it, just wait until real need
> arises. For now I'm more interested in hearing anyone saying that
> yess, this profiling thing has helped to make code better, and
> doesn't really slow squid down. I've had awfully little feedback
> y'know. ;)

I quite like it - I'm looking at it quite often, but poll() is the huge
culprit for me all the time. :}.

Rob