home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13022 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  1.4 KB
  1. Path: sparky!uunet!ogicse!usenet.coe.montana.edu!decwrl!csus.edu!borland.com!pete
  2. From: pete@genghis.borland.com (Pete Becker)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: BC 3.1 TV Running slow ?
  5. Message-ID: <1992Aug27.190831.4681@genghis.borland.com>
  6. Date: 27 Aug 92 19:08:31 GMT
  7. Article-I.D.: genghis.1992Aug27.190831.4681
  8. References: <1992Aug19.232224.3557@cssc-woll.tansu.com.au> <1992Aug27.073530.9986@info.ucl.ac.be>
  9. Sender: news@borland.com (News Admin)
  10. Organization: Borland International
  11. Lines: 17
  12. Originator: pete@genghis.borland.com
  13.  
  14. In article <1992Aug27.073530.9986@info.ucl.ac.be> vijghen@fynu3.fynu.ucl.ac.be (Philippe Vijghen) writes:
  15. >
  16. >I had the same problem with a Turbo Vision application and BC++ 3.0
  17. >compiler. I looked around for a long time and I found that the source
  18. >of the problem is the memory allocation mechanism: it uses a kind of
  19. >"safe pool" and a lot of verifications; this certainbly provide advantages
  20. >but the main result is a important reduction of the speed inside the
  21. >routines using dynamic memory allocation (I was doing some symbolic
  22. >computation to implement a fuzzy logic controller).
  23. >
  24. >I think that Borland should put an option in his library: speed/security
  25. >for the mem. alloc., don't you?
  26. >
  27.  
  28.     Actually, the problem is that the TV library as shipped was built with
  29. the debugging code left in.  If you recompile NEW.CPP with the switch -DNDEBUG
  30. all the debugging code will go away, and things will be much faster.
  31.