llama@eleazar.dartmouth.edu (Joe Francis) (07/31/90)
We are starting a project of several related applications in MPW C++. Long term plans include porting to other platforms. In the interest of ease of porting, it would be nice to use malloc/free instead of the mac specific memory manager calls. If any of you have experience with the MPW versions of these, could you please answer the following questions: 1) How does malloc/free actually work on the mac? 2) How is the performance? 3) Are there any problems you have run into? Advice needed and appreciated. Thanks, Joe DCIS project Dartmouth College ---------------------------------------------------------------------------- "Read My Lips: No Nude Texans!" - George Bush clearing up a misunderstanding
shebanow@Apple.COM (Andrew Shebanow) (08/01/90)
In article <23421@dartvax.Dartmouth.EDU> llama@eleazar.dartmouth.edu (Joe Francis) writes: >1) How does malloc/free actually work on the mac? >2) How is the performance? >3) Are there any problems you have run into? I discussed this in my article "Using C++ Objects In A Handle Based World," in Issue 2 (April 1990) of d e v e l o p. Its a little too long to repeat here, so I would encourage you to get a copy of the magazine. Its available by calling (800) 331-4164 (CA only) or (800) 443-9637 (US), or by writing: d e v e l o p Apple Computer, Inc. P.O. Box 531 Mt. Morris, IL 61054 malloc's performance is quite good, but it can have a detrimental effect on heap fragmentation, so you should avoid it if you also want to do "Mac-like" things (e.g, windows, menus, quickdraw, etc.). In general, I would strongly recommend against using it unless you are doing a straight port of a textual app - calling NewPtr is just as easy to write, and the storage headaches are a lot smaller (although the performance is, admittedly, quite a bit worse than malloc). Good luck, Andrew Shebanow DTS Engineer Emeritus Apple Computer, Inc.
cory@three.MV.COM (Cory Kempf) (08/05/90)
llama@eleazar.dartmouth.edu (Joe Francis) writes: >We are starting a project of several related applications in MPW C++. >Long term plans include porting to other platforms. In the interest >of ease of porting, it would be nice to use malloc/free instead of the >mac specific memory manager calls. Uh, C++ defines "new" and "delete" as part of the language. Why not use them? >If any of you have experience with the MPW versions of these, could >you please answer the following questions: >1) How does malloc/free actually work on the mac? Just about the same way as it does on any other platform -- it allocates a block of memory on the application heap. (nb: malloc returns a pointer, so of course the block is non-relocatable) Free does about what you would expect. >2) How is the performance? Don't know, never found any need to run benchmarks on memory allocation. In general, I find that my bottlenecks are in other areas (then again, I usually don't call malloc/free from within a tight loop -- and never (so far) in C++) >3) Are there any problems you have run into? Other than as noted above, none. +C -- Cory Kempf I do speak for the company (sometimes). The Enigami Co. 603 883 2474 email: cory@three.mv.com, harvard!zinn!three!cory
earleh@microsoft.UUCP (Earle HORTON) (08/08/90)
In article <9506@goofy.Apple.COM> shebanow@Apple.COM (Andrew Shebanow) writes: ... >malloc's performance is quite good, but it can have a detrimental >effect on heap fragmentation, so you should avoid it if you also want >to do "Mac-like" things (e.g, windows, menus, quickdraw, etc.). In >general, I would strongly recommend against using it unless you are >doing a straight port of a textual app - calling NewPtr is just as >easy to write, and the storage headaches are a lot smaller (although >the performance is, admittedly, quite a bit worse than malloc). The source to a basic storage allocator which is very much like malloc() may be found on pages 173-177 of "The C Programming Language" by Brian Kernighan and Dennis M. Ritchie, Prentice-Hall Software Series, 1978. This set of routines is comparable in performance to whatever is in the MPW runtime libraries. There is, however, the advantage that with source code you have access to compile-time constants which can be used to tune performance according to your own application's specific requirements. Examples are: minimum amount of storage to request from the operating system (NewPtr()) at a time, size of initial storage pool, maximum fraction of application heap to allocate before returning failure, etc. It is possible to implement and make use of malloc() or a similar storage allocator in such a manner that heap fragmentation is kept to a minumum. If you need a rather large storage pool for non-relocatable (i.e. malloc()ed) storage in your application, then you might want to consider partitioning your application heap into two separate storage areas. One area would be managed by the Macintosh Memory Manager, and the other by a simpler but faster memory manager like the storage allocator shown in K&R. Partitioning the heap is simple. Just allocate a large, non-relocatable block during the initialization phase, and free() it so that it becomes the storage pool used by malloc(). Note that this technique fails if the malloc() you are using ever returns storage to the operating system via DisposPtr() or some other mechanism. You want to maintain a large, contiguous pool of storage for use by malloc() and free() in order to maximize the performance of these routines and also minimize interference with "Mac-like" things. This may not be possible using the MPW library malloc(), but it certainly is possible using the storage allocator from K&R, or any other storage allocator for which you can get source code. A little experimentation might be necessary also to determine the best sizes for the malloc() storage pool and the Macintosh Memory Manager storage pool (i.e. whatever is left over). Make sure to leave enough storage to the system for extraordinary and emergency situations, and remember that system memory requirements can vary according to machine model. Disclaimers: I don't have anything to do with Kernighan and Ritchie, or Prentice-Hall, other than being a satisfied customer. These opinions are not necessarily related to any opinions that might be held by my employer. Earle Horton