>> If you are curious, those malloc happen at load time (before the 'run'
>> command), so you time starting ucsim, and then exiting within executing any
>> commands to test your theory that most of the time used is malloc being slow.
>> You would just need to make a copy of uCsim.cmd, remove the line with
>> 'run' and time the execution.
> real 0m0.154s
> user 0m0.012s
> sys 0m0.032s
> So, not much time is spent there.
Easy to say after the fact, but that was to be expected: malloc of
small amounts of memory is usually pure user-space code, which runs
unaffected by virtualization (no overhead here).
Virtual machines tend to have a high(er) impact on (a) system calls /
thread switches / kernel- vs. usermode transitons and (b) I/O access
latency (included in (a), but even more costly due to device emulation
overhead). Intuitively, I would rule out (b) as the culprit here,
which leaves (a) to be investigated. Does the simulator use a lot of
* read(), write() (depending on the library, these might be
efficiently processed on library-mmapped files or go through the VMM
into the guest OS)?
* inter-process communication?
* multiple threads in general?
* usleep() / nanosleep() / ...?
$ strace -c ucsim [args]
could shed some light on this. Other useful options to strace include
-F -f -T, all of which can be combined to arbitrarily verbose output
Just my 2c