Jukka Marin <jmarin@pyy.jmp.fi> wrote:

>>I would be glad if someone could give me simple instructions of how to
>>enable profiling in X and/or kernel (which one is it?) to finally find
>>out why Applixware runs so slow on NetBSD.

Ken Hornstein <kenh@cmf.nrl.navy.mil> replies;
>You know, _I_ would personally concentrate my time on doing a memory
>benchmark of the XFree InternalMalloc.  Would be a lot simpler than
>profiling the X server :-)
>
>I'm not up on profiling the kernel, but check out the gcc man page
>for the profiling flags (-pg, I think) and the "gprof" command.

Uh, I would first use systat vmstat or top to figure out if the time
is going in userspace or kernel space.  The hypothesis is that the
XFree InteralMalloc is known to work okay on Linux, so it can't be
solely InternalMalloc that's at fault.

This saga has gone on for what, a year now?  I wrote a brief note
explaining how to start kernel profiling ages ago; Curt Sampson turned
it into a Web page, somewhere off http://www.portal.ca/.

The guess here is that Linux' internal AVLtree mechanism for
representing process address space is more graceful at handling a very
very lange numbers of allocations and deallocations of very small VM
regions (e.g., maybe only one page?) than the rather simple
linked-list code in NetBSD.

Also, John Dyson said FreeBSD has tweaked some of the critical
linked-list code fragments and these reportedly make a difference.


OTOH, the UVM code is about to make it into NetBSD.  Maybe the best
thing is to ask Chuck Cranor or Matthew Green very nicely if they can
test and profile ApplixWare on the new VM code?