home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18269 < prev    next >
Encoding:
Text File  |  1992-12-21  |  2.9 KB  |  68 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mcsun!sunic!sics.se!eua.ericsson.se!euas62c36!euamts
  3. From: euamts@eua.ericsson.se (Mats Henricson)
  4. Subject: Re: Special-purpose-heap-managers - refere
  5. Message-ID: <1992Dec21.102620.21845@eua.ericsson.se>
  6. Sender: news@eua.ericsson.se
  7. Nntp-Posting-Host: euas62c36.eua.ericsson.se
  8. Reply-To: euamts@eua.ericsson.se
  9. Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
  10. References: <1992Dec20.153218.4338@daimi.aau.dk>
  11. Date: Mon, 21 Dec 1992 10:26:20 GMT
  12. Lines: 54
  13.  
  14. In article 4338@daimi.aau.dk, sabroe@daimi.aau.dk (Morten Sabroe Mortensen) writes:
  15. #euamts@eua.ericsson.se (Mats Henricson) writes:
  16. #
  17. #>In article 11510@daimi.aau.dk, sabroe@daimi.aau.dk (Morten Sabroe Mortensen) writes:
  18. #>#Could anyone, -who have tried-, tell, what kind of experiences they have with 
  19. #>#special-purpose-heap-managers like 'Pool', in what kind of program, with what 
  20. #>#kind of result/speed-up? 
  21. #
  22. #>We did a test of several class libraries, of which one was using a Pool class.
  23. #>In one test (putting and removing integers from a Set class) the Pool-based
  24. #>solution was ~20 times faster. That was the extreme case. In another test the
  25. #>gain was "only" 2.3 times.
  26. #
  27. #Nice, nice, - sounds interesting!!! 
  28. #Are some of these classes, you tested, availably on the net - 
  29. #do you remember where?
  30.  
  31. None of them can be fetched for free, I'm afriad - you have to pay for them!
  32. I don't want to hang them out on the net, but I can tell you the Pool-class
  33. library: USL Standard Components. Just to avarage out this free ego-boosting
  34. for the USL crowd, I can tell you that you can find some rather messy code
  35. in the USL SC (just an example):
  36.    -->grep -c goto getbuf.c 
  37.    5
  38. i.e. 5 goto:s in one single file!
  39.  
  40. #>BUT REMEMBER: all this performance difference is NOT because of a Pool class.
  41. #>The libraries differed in many other respects, which affected performance.
  42. #
  43. #>And then again: size and performance isn't everything...
  44. #
  45. #You're right! -size and performance isn't everything!
  46. #
  47. #BUT: If you want high performance, doing SOMETHING to dynamic allocation
  48. #     seems to be one of the better ways to gain speed, i think! 
  49. #     _IF_ allocation could be handled transparently, -like 'Pool' _nearly_ 
  50. #     can do, then.... But arrays...-one should be careful with arrays, 
  51. #     since they can't be managed transparently...YET! 
  52. #
  53. #It ought to be possible to let a special manager manage ALL kinds of
  54. #allocation involving a certain class, -that's what I want, I think!
  55. #TRUE TRANSPARENCY - ABSTRACTION, ABSTRACTION, ABSTRACTION - HIGHLY WANTED!
  56. #
  57. #I'm thinking: When constructing a special-purpose-heap-manager, one should
  58. #be careful not to ramble into some kind of ALIGNMENT-PROBLEM (it could
  59. #easily happen!!!) - that is, it should, -of course(!)-, be portable; 
  60. #size and performance isn't everything!
  61.  
  62. I don't know how portable the USL SC are.
  63.  
  64. Mats Henricson
  65. Ellemtel Telecom Systems Labs
  66. Stockholm
  67. Sweden
  68.