compute C program time

K

Kaz Kylheku

It would be possible to modify the program to perform the same
computation many times, but that's a pain, especially if the you have
to, say, add code to free data that would not otherwise be freed. Why
isn't there just a knob to set the sample frequency?

Use the kernel-based profiler oprofile. It profiles the whole system
at once, kernel and user space.
 
R

Richard Tobin

Keith Thompson said:
I wonder if you might improve performance by combining them into a
single executable, saving the overhead of program startup.

Yes, certainly. That would save a lot more, since it wouldn't have to
read in and write out the data as XML. But these are general purpose
utilities that other people are going to combine in unpredictable
ways.

-- Richard
 
K

Keith Thompson

Yes, certainly. That would save a lot more, since it wouldn't have to
read in and write out the data as XML. But these are general purpose
utilities that other people are going to combine in unpredictable
ways.

I was thinking of having the combined program do exactly what the
individual programs do now, which would only save the overhead of
program startup, but if the "sub-programs" can save time by passing
data to each other internally rather than by parsing and generating
XML, that's even better.

Maybe the single monolithic program could define a scripting
interface, allowing users to perform multiple operations without
ever leaving the program. Of course an invocation of any of your
existing programs could be replaced by a trivial script that just
performs one operation, perhaps specified on the command line.

(As an added bonus, and to get back to the topic of this thread,
you could probably get better profiling information using a script
that specifies doing the same action, say, 100 times.)

I don't know enough about what you're doing to know whether this
makes any sense.
 
S

Seebs

I was thinking of having the combined program do exactly what the
individual programs do now, which would only save the overhead of
program startup, but if the "sub-programs" can save time by passing
data to each other internally rather than by parsing and generating
XML, that's even better.
Yes.

Maybe the single monolithic program could define a scripting
interface, allowing users to perform multiple operations without
ever leaving the program. Of course an invocation of any of your
existing programs could be replaced by a trivial script that just
performs one operation, perhaps specified on the command line.

.... and I was about to say "this is the sort of thing that usually
calls for a domain-specific language".

-s
 
R

Richard Tobin

Maybe the single monolithic program could define a scripting
interface, allowing users to perform multiple operations without
ever leaving the program. Of course an invocation of any of your
existing programs could be replaced by a trivial script that just
performs one operation, perhaps specified on the command line.
[/QUOTE]
... and I was about to say "this is the sort of thing that usually
calls for a domain-specific language".

One has recently been developed:

http://www.w3.org/XML/XProc/docs/langspec.html

However, that doesn't mean it's not useful to be able to use traditional
shell scripts, especially if there are bits of non-XML processing in
there too. So yes, I'm aware of other possibilities, but I would still
like to be able to profile and speed up my short-lived C programs!

-- Richard
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top