home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / programm / 15862 < prev    next >
Encoding:
Text File  |  1992-11-15  |  3.4 KB  |  73 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!ukma!wupost!sdd.hp.com!hp-col!fc.hp.com!koren
  3. From: koren@fc.hp.com (Steve Koren)
  4. Subject: Unusual SAS6.0 results
  5. Sender: news@fc.hp.com (news daemon)
  6. Message-ID: <BxrwC8.3AG@fc.hp.com>
  7. Date: Sun, 15 Nov 1992 19:48:07 GMT
  8. Organization: Hewlett-Packard Fort Collins Site
  9. X-Newsreader: Tin 1.1.3 PL5
  10. Lines: 61
  11.  
  12. Ok, I'm clueless.
  13.  
  14. I upgraded from SAS 5.1b to 6.0, and recompiled some source with the
  15. new version, and am getting some interesting results, some of them
  16. a bit distrubing.
  17.  
  18. 1. I have a binary which I compiled under 5.10b and OS2.04.  It had
  19. no enforcer hits when run under OS2.04.  If I moved that same binary
  20. over to 3.0, it got a lot of enforcer hits.  If I recompiled the
  21. source under SAS6.0 and OS3.0, the very same source generates a binary
  22. which is back to getting no enforcer hits.  This is good, I guess,
  23. but I don't understand it.
  24.  
  25. 2. GENPROTO mode crashes the machine a lot.  I get consistant crashes
  26. on 2 out of 30 source files.  No big deal though; I can generate the
  27. prototypes by hand.
  28.  
  29. 3. This is the real thing I'm worried about.  I have about 22000 lines
  30. of source which is divided into 39 small executables and one medium
  31. sized executable.  The conversion process from 5.10b to 6.0 was relatively
  32. painless; 6.0 is a bit more strict about type checking, but other than
  33. than, it all compiled with no errors or warnings.  All the small
  34. executables (2-8K, a few hundred lines max) work just great under 6.0,
  35. and in fact are smaller than they were before.  They appear to run
  36. with the same speed.  However, the medium sized executable is not
  37. so happy.  It runs as before, but it is *much* slower.  I'm talking
  38. about 20X here.  It is getting no enforcer hits; I've checked that.  Since
  39. I really wanted to get it back to its old execution speed, I did a
  40. lprof and lstat on it.  I'm getting _really_ wierd results.  Here is
  41. the 1st few lines from the lstat output:
  42.  
  43.  95.4023%  95.4023%   f97c      249 _strncpy  <- I DON'T CALL THIS!
  44.   0.7662%  96.1685%   7c58        2 @Read_String [lines 290-327 in Lexer.c]
  45.   0.7662%  96.9349%   92d4        2 _yyparse [lines 966-1103 in Parser.y.C]
  46.  
  47. I'm apparently spending 95% of my time in strncpy, which is really wierd
  48. because I don't actually _call_ strncpy anywhere in my source.  I searched
  49. every single source file and nothing calls strncpy.  I do call strcpy, but
  50. not very much.  I ran the debug executable through cpr, put a breakpoint
  51. on strncpy, and executed, and I never hit it.  I don't even understand why
  52. it is being linked into my code (but it is, I checked that).
  53.  
  54. The profile results when I compile this source under 2.04 with SAS5.10b
  55. look "normal".  There is a more or less even distribution of time spent in
  56. the routines I expect.  But under 6.0, all my time is spent in this mystical
  57. strncpy which I don't even think I'm calling.
  58.  
  59. What's going on?  Interestingly enough, the strncpy is taking ~95% of the
  60. execution time, and my program is running about 95% slower than it was
  61. before.  Dunno if that's a coincidence or not.  I do need to get it back
  62. to its 5.10b execution speed though.
  63.  
  64. BTW, the program which is running 20X slower basically does this: some
  65. FGets() calls, a bit of processing to build a parse tree out of that
  66. data, and an execution of that parse tree.  The rough times I see are:
  67.  
  68.   Old 5.10b executable: 1 second
  69.   New 6.0 execeutable:  15 to 20 seconds
  70.  
  71.   - steve "confused" k
  72.  
  73.