Average execution time - c

is there any nice GNU way how to measure average (worst case, best case) execution time of some command line program? I have image filter, unspecified amount of pictures, filtering them using for-loop in bash. So far I am using time, but I can't find a way how to get some statistics.

You can send the output of time to some file, and then "work" that file
echo "some info" >> timefile.txt
time ( ./yourprog parm1 parm2 ) 2>> timefile.txt

There's an interesting Perl program called dumbbench that's essentially a wrapper around the time command. It runs your program a number of times, throws away outliers, then calculates some statistics.
The author has a couple of articles (here and here) outlining a) why benchmarking sucks, and b) what kind of pretty graphs you can make to make your benchmarking numbers suck a little less.

You're on the right track with time. It's what I use to preform small code execution analyses.
I then use python to collect the statistics by reading the output of time. In order to increase accuracy, I typically do the trial 10 - 1000 times, depending on how long each process takes.
I'm not familiar with any pre-installed GNU application that does this sort of analysis.

#!/bin/bash
for i in {1..100}
do
env time --append -o time_output.txt ./test_program --arguments-to-test-program
done
exit
If you find that the {1..100} syntax doesn't work for you then you should have a look at the seq command.
I used the env time to execute the time program rather than the shell's built in command, which does not take all of the arguments that the time program takes. The time program also takes other arguments to alter the format of it's output, which you will probably want to use to make the data easier to process by another program. The -p (--portability) argument makes it output in the POSIX format (like BASH's builtin time does), but using the -f option you can get more control. man 1 time for more info.
After you have gathered your data a simple perl or python script can easily parse and analyze your timing data.

You should consider whether to time the outer loop and divide by the repetitions rather than timing each iteration separately. If you're worried about discarding the high and low, just do a few more iterations to drown them out.
time for i in {1..1000}
do
something
done
You can capture the output from time in a variable:
foo=$( { time {
echo "stdout test message demo"
for i in {1..30}
do
something
done
echo "stderr test message demo" >&2
} 1>&3 2>&4; } 2>&1 )
and do some fake math:
foo=${foo/.} # "divide" by ...
echo "0.00${foo/#0}" # ... 1000
Or just use bc:
echo "scale=8; $foo/1000" | bc

Related

LLDB make command from script

I created step-scripted that print for me the name of function the debugger calls.
Now I want to automate the part that I need to type:
thread step-scripted -C MyTrace.Trace
How can I run the above command from a script?
so I will do something like this:
script
while True:
thread step-scripted -C MyTrace.Trace
First off, there's no reason that a step plan has to do just one step. If you want to step forever, then just have the step plan do it - never set the plan to complete, and return false from should_stop. Even more convenient, if you are using a recent lldb, you can pass arguments to your scripted step plan using the -k <key> -v <value> arguments. So you could also have your plan take a "count" input, and step that many times.
Otherwise, the easiest way to do this is to use the Python interface to implement a custom command that automates this step. SBThreads are the things you step. If you use the command form that takes an SBExecutionContext, described here:
https://lldb.llvm.org/use/python-reference.html#id6
you can get the thread from SBExecutionContext.thread then use SBThread. StepUsingScriptedThreadPlan to call your thread plan to do the step. Once you are in python, writing a loop to do this forever or till some condition, etc. should be easy. Your command could also take number of times to step, etc.
Note, you can also run commands in the script interpreter using SBCommandInterpreter.HandleCommand if that seems easier to you.

How to write a script to run a program multiple times and store the time in a file?

I am trying to run a script to run my program written in C that is just a simple sorting program to compare it to the built in function in unix. I want to take the user time from both sort (unix) and my sort function 100 times and put it in a file excel, csv to compare the algorithms.
Both my function and the sort function work when I run it manually but I dont know how to write code to automate this process for 100 times.
#!/bin/sh
for i in {1..100}
do
for t in 01
do
echo ===Test $t ====
time sort -n <tests/$t > tests/$t.expected
time ./useIntList <tests/$t> tests/$t.observed
done
done
rm tests/*.expected tests/*.obsereved
I get the program run 100 times but I dont know how to get the user time into an array and print it into a file.
time writes its output to stderr, not stdout. It's also a shell built-in that executes the command after it, including the I/O redirections, outside the timing. So you need to put the time command in a block, and redirect outside the block.
You should also use #!/bin/bash. Syntax like {1..100} is a bash extension, it might not be available when you use #!/bin/sh.
#!/bin/sh
for i in {1..100}
do
for t in 01
do
echo ===Test $t ====
{ time sort -n <tests/$t > tests/$t.expected; } 2>tests/$t.time.expected
{ time ./useIntList <tests/$t> tests/$t.observed; } 2>tests/$t.time.observed
done
done
rm tests/*.expected tests/*.obsereved
The *.time.* files will contain the output of time.

How to display top largest files in a non blocking manner on linux?

For years I have being using variasons of du command below in order to produce a report of the largest files from specific location, and most of the time it worked well.
du -L -ch /var/log | sort -rh | head -n 10 &> log-size.txt
This this proved to get stuck in several cases, in a way that prevented stopping it with even the timeout -s KILL 5m ... approach.
Few years back this was caused by stalled NFS mounts but more recently I got into this in on VMs where I didn't use NFS at all. Apparently there is a ~1:30 chance to get this on openstack builds.
I read that following symbolic links (-L) can block "du" in some cases if there are loops but my tests failed to reproduce the problem, even when I created some loop.
I cannot avoid following the symlinks because that's how the files are organized.
What would be safer alternative to generate this report, one that would not block or at least if it does, it can be constrainted to a maximum running duration. It is essential to limit the execution of this command to a number of minutes -- if I can also get a partial result on timeouts or some debuggin info even better.
If you don't care about sparse files and can make do with apparent size (and not the on-disk size), then ls should work just fine: ls -L --sort=s|head -n10> log-size.txt

Difference bewteen using shell command "command time -v" and C function "getrusage"?

I want to know the Maximum resident set size of a the execution of a shell file (which is launching C program).
Is there any difference of result between those two solutions :
command time -v ./file.sh
calling getrusage() function in my C program
I tried both and it seems clearly similar to me ... but I would like approval :)

How to identify gnome-terminal profile?

I posted a question on askubuntu a while back. As there is no action, and I have also dug some more, I'll try here. Possibly a more correct place, (and I don't know if it is possible to move questions any more (I do not get any of those options)).
Anyhow:
Is there a way to get gnome-terminal profile ID? Need it in bash script – to do e.g. –
gconftool-2 "do some change to some value for current profile."
In my endeavour for an answer to this I have made some progress – but no satisfying solution. To be honest it truly scares me how shielded the application is from doing modifications from command line being a terminal emulator! To me it is incomprehensible.
Besides touching the source of gnome-terminal, (I do not wan a custom version), is there some legit way to get this? By the fact it is a wrapper for vte, it uses various shared libraries, some way I haven’t thought of, etc.
Add some C code into the mix is OK.
So far:
I have checked out the "save-config" option, but as it is 1. not satisfactory, aka 100%, and 2. more important this also is going to be removed it fails completely. See my own answer below for more detail.
There is no environment variable for this.
dbus: Doesn't seem to be any messages transmitted or any functions available for this kind of information. Have tested both current (3.6.0) version and latest develop.
injection: tho it is probable, and have played around with injecting custom code to it, it is such an error-prone endeavour it is not a solution.
If anyone wonder etc.
Decided to have another look at this - and made a little progress.
Using the built-in option --save-config there is these properties of interest:
Role=gnome-terminal-window-2587-1856448950-1359348087
ActiveTerminal=Terminal0xa896200
Geometry=110x87+900+1
WorkingDirectory=/home/xxx/tmp
Looking at it closer. Opened two windows in short succession and did a save-config.
Role
We can split it to the various parts:
gnome-terminal-window
2587
1856448950
1359348087
PID
2587 is same for both, and after a quick pstree 2587 -p we find it to be the PID. Further an echo $$ locates our bash (or which ever one prefer).
Time of start
Now the second number is wildly different giving a clue it is probably a random value. The last one, tho, is with only the last digit in diff. Most probably a time-stamp. I know I'm in tmp directory for this window - so, by using our knowledge of the proc file system:
# btime: boot time, in seconds since the Epoch
$ cat /proc/stat | grep ^btime | cut -d' ' -f2
1359039155
# starttime: The time in jiffies the process started after system boot.
$ cat /proc/$$/stat | cut -d' ' -f22
30893222
# WANT: 1359348087
btime + starttime / Hertz
1359039155 + (30893222 / 100) = 1359348087.22 ~ 1359348087
OK. Last digit is time-stamp on start by Epoch. But unfortunately it is not by jiffies and a rounded value so if we have started several windows by e.g. a script we can end up with same value.
(After some checking it also seems like seconds is rounded by round to nearest not towards zero etc.)
Random value
OK. So what about the value after PID? Most probably a random value, but to be sure. To check this we have to go to the source.
$ git clone git://git.gnome.org/gnome-terminal
$ gnome-terminal --version
GNOME Terminal 3.6.0
$ git log --grep="3\.6\.0"
commit f4d291a90dc4f513fc15f80fdebcdc3c3349b70a
...
Version 3.6.0
$ git checkout f4d291a90dc4f513fc15f80fdebcdc3c3349b70a
After some digging we find:
# terminal-util.c
48: void
terminal_util_set_unique_role (GtkWindow *window, const char *prefix)
{
char *role;
role = g_strdup_printf(
"%s-%d-%d-%d",
prefix,
getpid(),
g_random_int(),
(int) time (NULL)
);
gtk_window_set_role (window, role);
g_free (role);
}
OK. Not only do we confirm that the second is a random value, but also that PI and time is correct.
Geometry
xwininfo -id $(xdotool getactivewindow) | \
grep '^\s*-geometry' | \
sed 's/^\s*[^ ]* \(.*\)/\1/'
# yields 110x87+900+1
OK. Now we have three values to check against:
Time
Geometry
Path
Problem is that even with this we can easily have two windows with those values at same value. And more important; some genius has decided to remove this from the options of the application.
Terminal Window hex
Looking further at the code one find that the hex value in ActiveTerminal etc. is a pointer value to current address in memory of a struct holding current window. AKA not very usefull if one doesn't want to hack memory mappings.

Resources