home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12956 < prev    next >
Encoding:
Text File  |  1992-08-26  |  2.4 KB  |  59 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mcsun!ub4b!info-sparc1.info.ucl.ac.be!fynu.ucl.ac.be!vijghen
  3. From: vijghen@fynu3.fynu.ucl.ac.be (Philippe Vijghen)
  4. Subject: Re: BC 3.1 TV Running slow ?
  5. Message-ID: <1992Aug27.073530.9986@info.ucl.ac.be>
  6. Sender: news@info.ucl.ac.be (News Administrator)
  7. Nntp-Posting-Host: topo2
  8. Organization: Free University of Brussels (ULB) - Astrophysic Dpt.
  9. References: <1992Aug19.232224.3557@cssc-woll.tansu.com.au>
  10. Date: Thu, 27 Aug 1992 07:35:30 GMT
  11. Lines: 46
  12.  
  13. In article <1992Aug19.232224.3557@cssc-woll.tansu.com.au> greg@cssc-woll.tansu.com.au (Pengelly Greg) writes:
  14. >
  15. >
  16. >Problems with Turbo Vision V3.1
  17. >
  18. >We have a reasonably large TV application developed under BC V3.0
  19. >Compiled under BC V3.1 it runs like a dog. 
  20. >The application now runs noticably slower. 
  21. >Compiler switches and source code have not been changed.
  22. >
  23. >Has anyone else had this problem. Better still can anyone provide the 
  24. >solution.  Help from Borland Australia has sofar been nonexistant.
  25. >
  26.  
  27. I had the same problem with a Turbo Vision application and BC++ 3.0
  28. compiler. I looked around for a long time and I found that the source
  29. of the problem is the memory allocation mechanism: it uses a kind of
  30. "safe pool" and a lot of verifications; this certainbly provide advantages
  31. but the main result is a important reduction of the speed inside the
  32. routines using dynamic memory allocation (I was doing some symbolic
  33. computation to implement a fuzzy logic controller).
  34.  
  35. The only solution I found was to do an "execvp(...)" call to a non
  36. Turbo Vision excutable! I think another one should be to rewrite the
  37. allocation function new (Yes, it's possible because Borland provides
  38. the source of every single function of his libraries!) ...but the
  39. code should'nt be as portable.
  40.  
  41. The execvp() was not a problem for my applications because the computation
  42. time was in days on a 486!!! (because of a Genetic Algorithm optimisation
  43. with a trcky fitness function...) I understand that for other applications
  44. it should not be a good solution. 
  45.  
  46. I think that Borland should put an option in his library: speed/security
  47. for the mem. alloc., don't you?
  48.  
  49. Anyway, I really enjoy the Borland C++ package (I am waiting for an upgrade
  50. to the version 3.1) and I think that no compiler is going better an better
  51. as it does.
  52.  
  53.     Philippe VIJGHEN
  54.     Ingenieur Civil Mecanicien et Electricien (AIrBr)
  55.     Free University of Brussels (ULB)
  56.     Astrophysic -Dpt.
  57.  
  58.     e-mail: vijghen@fynu.ucl.ac.be
  59.