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.