[SAGA-RG] profiling

[Andre Merzky]

Uhm, sorry - this went to the wrong list - should have gone to our
C++ impl list *blus*

My apologies, 

  Andre.


Quoting [Andre Merzky] (Jan 24 2010):
> Date: Sun, 24 Jan 2010 00:59:53 +0100
> From: Andre Merzky <andre at merzky.net>
> To: SAGA RG <saga-rg at ogf.org>
> Subject: Re: profiling
> 
> Ah, forgot to mention: this was on MaxOS with svn trunk #4507, in
> case that this makes any difference...
> 
> A.
> 
> 
> Quoting [Andre Merzky] (Jan 24 2010):
> > 
> > Hia folx, 
> > 
> > Having too much time (*ahem-lack-of-focus-ahem*), I run a profiler
> > against saga-job.  Attached is the result.  The command line was:
> > 
> >   ./saga-job run fork://localhost /bin/date
> > 
> > Walltime is consistently about 2 seconds, while a simple test
> > program just doing fork/exec takes no measurable time.  Now, this is
> > of course not fair comparision, but I wanted to know where the time
> > is spent anyway.  
> > 
> > The profiler gave me the figure attached as saga_job.prof_1.pdf .
> > It turns out that most time is in fact spent in boost::uuid, which
> > gets called a whopping 125 times, eating abouyt 89% of the run time.
> > To me it looks like it is trying to re-seed the random number
> > generator over and over again?  
> > 
> > So, I took the liberty to implement a much more stupid uuid
> > generator, which simply assigns an integer as uuid (see attached
> > uuid.hpp, which replaces saga/impl/engine/uuid.hpp), and indeed the
> > runtime for the same command line decreases to about 0.5 seconds,
> > which are now mostly spent in ini file parsing and adaptor loading,
> > as it should be (see saga_job.prof_2.pdf).  Morover, that time
> > should be constant per application instance, whereas the uuid time
> > was likely proportional to the number of SAGA calls (or objects)
> > used by the application.
> > 
> > Now, I am not claiming that we should use this overly simple uuid
> > generator (although it should create 4.294.967.295 unique IDs per
> > application instance), but in any case, the uuid generator could do
> > with some improvement.  I did not really understand the boost code
> > well enough to see why the seeding is triggered so often, but maybe
> > Hartmut has an idea, or someone else comes up with a cheap
> > alternative.
> > 
> > Cheers, Andre.
-- 
Nothing is ever easy.