frans@phcisa.UUCP (Francois Staes) (08/28/90)
Hello, before some day I saw an article saying that for a performnace increase of X applications using a widget based toolkit, one shoudl try to find a faster memory allocator. Can smoebody tell me where I can find such a fast memory allocator ? Can I simply use the malloc.c file as distributed with e.g. emacs ? Thanks in advance, Francois Staes Origin Middleware Eindhoven, The Netherlands. Email : frans@ait.origin.nl (previously frans@ait.philips.nl)
rlh2@ukc.ac.uk (Richard Hesketh) (08/28/90)
In article <1141@phcisa.UUCP>, frans@phcisa.UUCP (Francois Staes) writes: |> Can smoebody tell me where I can find such a fast memory allocator ? |> Can I simply use the malloc.c file as distributed with e.g. emacs ? Yes this seems to work just fine. Infact it is *extremely* quicker when a large number of widgets need to be created. I have just tried this with an application that creates >100 widgets and here's the two "time"s for SPARCstations: With libc malloc: 16.9u 1.2s 0:23 77% 0+2112k 61+0io 51pf+0w With GNU malloc: 6.4u 1.5s 0:15 52% 0+2456k 4+0io 130pf+0w This is a very rough comparison but shows what I have found in practice, the GNU malloc is over twice as quick for widget widget creation than the libc malloc. It has reduced my applications start up time from 28 seconds to 11 seconds (on a SPARC). Here comes the wish then ... how about a malloc written just for Xt and included in the R5 release? I wouldn't want to say "just use the GNU malloc" because of copyright restrictions. -- Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk : rlh2@ukc.ac.uk ..!mcsun!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 7620/3682
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (08/28/90)
In fact it is *extremely* quicker when a
large number of widgets need to be created.
It would be equally interesting to know how the process size compares.
My previous experience with Sun's malloc in the X server has been that
it does rather a good job of keeping the process size down, but seems
to trade off some speed to achieve this.
how about a malloc written just for Xt and included
in the R5 release?
No thank you. I'd say you appear to be blindly attacking a symptom rather
than a cause. E.g., how about a revised Xt implementation instead, one that
doesn't allocate so bloody many bits and pieces? (Or how about a new spec? :-)thp@westhawk.UUCP ("Timothy H Panton.") (08/28/90)
> Can I simply use the malloc.c file as distributed with e.g. emacs ? Yup, it gets you up to a factor of 2 on some systems. Tim. +----------------------------------------------------------------------------+ |Tim Panton, Westhawk Ltd. "... avoiding vain and profane babblings." | |Phone: +44 92822574 -1 Timothy 6:20. | |uucp : ..!mcvax!ukc!westhawk!thp | |Paper: Westhawk Ltd. 26 Rydal Grove, Helsby, Cheshire, WA6 OET. UK. | +----------------------------------------------------------------------------+
frose@synoptics.COM (Flavio Rose) (08/29/90)
Bob Scheifler writes in response to performance complaints: "How about a revised Xt implementation instead, one that doesn't allocate so bloody many bits and pieces? (Or how about a new spec? :-)" Indeed performance improvements for Xt based applications would be my personal number one priority for R5. But I'm not sure what is meant by a "new spec" (especially with the smiley face immediately following). Would it be a wise idea to try to invent a replacement for the Xt Intrinsics, one that has similar scope, but is incompatible in detail to get better performance? Yours truly, Flavio Rose
ron@xwind.UUCP (Ronald P. Hughes) (08/29/90)
In article <1141@phcisa.UUCP> frans@phcisa.UUCP (Francois Staes) writes: > >Can smoebody tell me where I can find such a fast memory allocator ? You don't mention what machine you're using. The first place to look is in your system's documentation. HP and Apple, for instance, provide alternative memory allocators (I am of the opinion that the version shipped with A/UX 1.0 was defective). If you're using a Sun, don't bother--their memory allocator is adequate. Ronald P. Hughes ron@xwind.com (or ...!uunet!xwind!ron) CrossWind Technologies, Inc. 408-335-4988
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (08/29/90)
In article <5354@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh) writes: >In article <1141@phcisa.UUCP>, frans@phcisa.UUCP (Francois Staes) writes: >|> Can smoebody tell me where I can find such a fast memory allocator ? >|> Can I simply use the malloc.c file as distributed with e.g. emacs ? > >Yes this seems to work just fine. Infact it is *extremely* quicker when a >large number of widgets need to be created. I have also found similar improvements when I use HP's -lmalloc (malloc(3X)) in Xtoolkit-based programs. Which other machines have a "fast malloc library" as part of their standard Un*x libraries? I'm particularly interested in (not necessarily in order of interest): (1) Sun, (2) DEC RISC, (3) MIPS, (4) Data General Aviion, (5) Apollo > Here comes the wish then ... how about a malloc written just for Xt and included > in the R5 release? I wouldn't want to say "just use the GNU malloc" because > of copyright restrictions. What about the andrew malloc library?? It has an MIT X Consortium style copyright. It is located in X11r4:contrib/toolkits/andrew/overhead/malloc I did notice the following warning from the file malloc.help: | The current incarnation of the allocator is unsuitable for direct use in a | large virtual environment where many small blocks are to be kept, since it | keeps all allocated and freed blocks on a single circular list. Just before | more memory is allocated, all allocated and freed blocks are referenced; this | can cause a huge number of page faults. | ??? ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
randy@erik.UUCP (Randy Brown) (08/29/90)
>Which other machines have a "fast malloc library" as part of their standard >Un*x libraries? I'm particularly interested in (not necessarily in order of >interest): > (1) Sun, (2) DEC RISC, (3) MIPS, (4) Data General Aviion, (5) Apollo Well, they're not HARDLY on your list, but /usr/lib/libmalloc.a exits on the Unix that Motorola Microcomputer Division ships on the boxes they call Delta 3000's, 680x0-based systems that have X client libraries and servers optional, and of course System V/386 (AT&T, etc.) has libmalloc.a as well. Only thing is, when I use -lmalloc on the Motorola, none of the clients work; all I get is "cannot open display." Sigh. (I tried adding a call to mallopt to set M_KEEP; no joy. I haven't tried the 386 yet to see if this is a generic bug or one Motorola has provided as added value or merely some stupidity on my part...) Randy Brown (uunet!erik!rbrown)
mikeo@sae.UUCP (Michael Ovington) (08/30/90)
>Which other machines have a "fast malloc library" as part of their standard >Un*x libraries? I'm particularly interested in (not necessarily in order of >interest): >(1) Sun, (2) DEC RISC, (3) MIPS, (4) Data General Aviion, (5) Apollo DG/UX also has an alternative malloc (malloc(3x)) that is faster than the standard DG/UX malloc(3c). The man page says it typically requires more memory than the standard malloc, but it can be tuned to to an amazing degree, so that it's best at allocating chunks of a specific size. ________________________________________________________________________________ Michael S. Ovington Software A&E (703) 276-7910 1600 Wilson Blvd, Suite 500 uunet!sae!mikeo Arlington, VA 22209 mikeo@sae.com ________________________________________________________________________________
melby@daffy.yk.Fujitsu.CO.JP (John B. Melby) (09/14/90)
One thing that I would like to see in future Xt implementations is a facility for sharing font data between processes. Currently, each copy of kterm opened on the screen appears to require its own copy of the kanji font. Of course, this can be avoided if one patches the client to fork out copies of itself, but it would be preferable to be able to share a memory font between two totally unrelated processes. ----- John B. Melby Fujitsu Limited melby%yk.fujitsu.co.jp@fai.com