mallopt (Re: [Python-Dev] Minor compilation problem on HP-UX (1.6b1) (fwd))

[Jack Jansen]

Don't worry, Vladimir, I hadn't forgotten your malloc stuff:-) Its just that 
if mallopt is available in the standard C library this may be a way to squeeze 
out a couple of extra percent of performance that the admin who installs 
Python needn't be aware of. And I don't think your allocator can be dropped in 
to the standard distribution, because it has the potential problem of 
fragmenting the heap due to multiple malloc packages in one address space (at 
least, that was the problem when I last looked at it, which is admittedly more 
than a year ago).

And about mallopt not being portable: right, but I would assume that something 
like
#ifdef M_MXFAST
	mallopt(M_MXFAST, xxxx);
#endif
shouldn't do any harm if we set xxxx to be a size that will cause 80% or so of 
the python objects to fall into the M_MXFAST category 
(sizeof(PyObject)+sizeof(void *), maybe?). This doesn't sound 
platform-dependent...

Similarly, M_FREEHD sounds like it could speed up Python allocation, but this 
would need to be measured. Python allocation patterns shouldn't be influenced 
too much by platform, so again if this is good on one platform it is probably 
good on all.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm