home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18254 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.5 KB
  1. Path: sparky!uunet!usc!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!dkuug!daimi!sabroe
  2. From: sabroe@daimi.aau.dk (Morten Sabroe Mortensen)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Special-purpose-heap-managers - references
  5. Message-ID: <1992Dec20.153218.4338@daimi.aau.dk>
  6. Date: 20 Dec 92 15:32:18 GMT
  7. References: <1992Dec18.110536.11510@daimi.aau.dk> <1992Dec18.120948.5677@eua.ericsson.se>
  8. Sender: news@daimi.aau.dk
  9. Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
  10. Lines: 44
  11.  
  12. euamts@eua.ericsson.se (Mats Henricson) writes:
  13.  
  14. >In article 11510@daimi.aau.dk, sabroe@daimi.aau.dk (Morten Sabroe Mortensen) writes:
  15. >#Could anyone, -who have tried-, tell, what kind of experiences they have with 
  16. >#special-purpose-heap-managers like 'Pool', in what kind of program, with what 
  17. >#kind of result/speed-up? 
  18.  
  19. >We did a test of several class libraries, of which one was using a Pool class.
  20. >In one test (putting and removing integers from a Set class) the Pool-based
  21. >solution was ~20 times faster. That was the extreme case. In another test the
  22. >gain was "only" 2.3 times.
  23.  
  24. Nice, nice, - sounds interesting!!! 
  25. Are some of these classes, you tested, availably on the net - 
  26. do you remember where?
  27.  
  28. >BUT REMEMBER: all this performance difference is NOT because of a Pool class.
  29. >The libraries differed in many other respects, which affected performance.
  30.  
  31. >And then again: size and performance isn't everything...
  32.  
  33. You're right! -size and performance isn't everything!
  34.  
  35. BUT: If you want high performance, doing SOMETHING to dynamic allocation
  36.      seems to be one of the better ways to gain speed, i think! 
  37.      _IF_ allocation could be handled transparently, -like 'Pool' _nearly_ 
  38.      can do, then.... But arrays...-one should be careful with arrays, 
  39.      since they can't be managed transparently...YET! 
  40.  
  41. It ought to be possible to let a special manager manage ALL kinds of
  42. allocation involving a certain class, -that's what I want, I think!
  43. TRUE TRANSPARENCY - ABSTRACTION, ABSTRACTION, ABSTRACTION - HIGHLY WANTED!
  44.  
  45. I'm thinking: When constructing a special-purpose-heap-manager, one should
  46. be careful not to ramble into some kind of ALIGNMENT-PROBLEM (it could
  47. easily happen!!!) - that is, it should, -of course(!)-, be portable; 
  48. size and performance isn't everything!
  49.  
  50.         -- Morten.
  51.  
  52. ---------------------------------------------------------------------------
  53.  Morten Sabroe Mortensen,         e-mail: sabroe@daimi.aau.dk
  54.  Department of Computer-science - University of Aarhus, Denmark.
  55. ---------------------------------------------------------------------------
  56.