On Sun, Apr 20, 2003 at 12:11:04PM -0600, Jim Bernard wrote:
>   Gprof shows a general slowdown, though the computation time is, in both
> cases, almost all in two routines.

A bit hard to poke at without knowing the structure of those routines,
but if one is (for example) a big loop, you could put a utrace() call in
the loop. Then the ktrace records should match one set of 

fast			slow(1)		slow(2)
1			1		1.2
2			2		2.4
3			3		3.6
4			4		4.8
loop begins
5			5.25		6
6			6.5		7.2
7			7.75		8.4
8			9		9.6
loop ends
9			10		10.8
10			11		12
11			12		13.2
12			13		14.2

If it's the slow(1) case, you could give us a piece of the code in the
loop, if you can share it.

>   Ktrace's timestamps show all the time going into the calculation, which
> is a single step in its output.  That is, there are entries for the various
> startup items and for reading the input, then a big time jump to the next
> entry, during which the calculation takes place, then entries for output
> and termination.  In short, no new insight.
> 
>   See my response to Ben's message for some additional, possibly relevant,
> info.
> 
>   Thanks for the suggestion.  If you have more, I'll be glad to hear them.

How about compiling with '-g', then time a run in a shell. Then time a
run (in the same shell) under gdb. Then use gdb to print the addresses
of the variables whose alignment concerns you.

Then repeat in a shell which has the other timing property.

I'll be surprised if the variables end up at different addresses (unless
you program does mallocs, which are affected by random input data
because it's doing crypto of some sort) - but it would be informative in
diagnosing the problem if that is the case.

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
Any sufficiently advanced Common Sense will seem like magic... 
					      - me