[SAGA-RG] profiling

[Andre Merzky]

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.