|Do you know where your variables are?|
Re: Speeding up external command executionby graff (Chancellor)
|on Apr 14, 2014 at 00:24 UTC||Need Help??|
While RAM limitations are rarely a concern these days, it's about the only thing I can imagine that might cause the timing difference (apart from possible environment differences hinted at by soonix above) - i.e. the java process takes 5-6 seconds, given the available RAM when it's running alone, but if your perl script is running at the same time (and if it takes up a lot of RAM), then you might lose a lot of time to memory swapping (aka page faults). BrowserUK's suggestion will show you if that's the issue.
Apart from the timing issues, the logic you're using to build the command line is strange. I would have done it something like this:
My version should yield the same behavior as yours, but if, instead of using "master*.svg", you were to use the actual list of file names (that is, the names of the svg files that were just created previously in your script), like this:
then the method of execution will be slightly different. If you haven't read perldoc -f system, you might find that interesting.
I expect that after you generate all those "fairly complicated SVGs", you close those file handles (i.e. make sure all the output has been flushed) before doing the system call. If those file handles are still open, perl will flush them for you when you do the system call, which might add a bit of delay.
Your description suggests that the system call is only being done once; if you were doing a lot of similar system calls in some sort of loop, then one possible cause of delay would be the extra overhead of invoking and cleaning up after a subshell on each iteration; one way to get around that (on a *n*x system) would be:
But that's probably not relevant here.