home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / programm / 15902 < prev    next >
Encoding:
Text File  |  1992-11-16  |  3.7 KB  |  86 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!gatech!concert!sas!mozart.unx.sas.com!walker
  3. From: walker@twix.unx.sas.com (Doug Walker)
  4. Subject: Re: Unusual SAS6.0 results
  5. Originator: walker@twix.unx.sas.com
  6. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  7. Message-ID: <BxtBBu.L5w@unx.sas.com>
  8. Date: Mon, 16 Nov 1992 14:09:30 GMT
  9. References:  <BxrwC8.3AG@fc.hp.com>
  10. Nntp-Posting-Host: twix.unx.sas.com
  11. Organization: SAS Institute Inc.
  12. Lines: 72
  13.  
  14.  
  15. In article <BxrwC8.3AG@fc.hp.com>, koren@fc.hp.com (Steve Koren) writes:
  16. |> 2. GENPROTO mode crashes the machine a lot.  I get consistant crashes
  17. |> on 2 out of 30 source files.  No big deal though; I can generate the
  18. |> prototypes by hand.
  19.  
  20. We fixed a bug in GENPROTO for the upcoming 6.1 patch that may fix
  21. your problem, but if you want to make sure it gets fixed, contact
  22. technical support with a test case.  You can use the EMITS facility,
  23. described in the "Getting Help" chapter of the User's Guide, to 
  24. report the problem via email.
  25.  
  26. |> with the same speed.  However, the medium sized executable is not
  27. |> so happy.  It runs as before, but it is *much* slower.  I'm talking
  28. |> about 20X here.  It is getting no enforcer hits; I've checked that.  Since
  29.  
  30. No idea what is going on without source code or a runnable program to 
  31. look at.  There is nothing in 6.0 that should have caused this.
  32. For such a dramatic difference, there has to be something different
  33. in the way the program is linked - different library functions,
  34. different startup, something.
  35.  
  36. |> I really wanted to get it back to its old execution speed, I did a
  37. |> lprof and lstat on it.  I'm getting _really_ wierd results.  Here is
  38. |> the 1st few lines from the lstat output:
  39. |> 
  40. |>  95.4023%  95.4023%   f97c      249 _strncpy  <- I DON'T CALL THIS!
  41. |>   0.7662%  96.1685%   7c58        2 @Read_String [lines 290-327 in Lexer.c]
  42. |>   0.7662%  96.9349%   92d4        2 _yyparse [lines 966-1103 in Parser.y.C]
  43.  
  44. First, strncpy may be called by a library function that you call.
  45. Use the MAP and MAPXREF options to generate a linker cross-reference
  46. and see who is calling strncpy.  You'll find some lines in the cross-
  47. reference like the following:
  48.  
  49. symbol   (Def) module  Off (Ref) Module  Off (Ref) Module  Off (Ref) Module  
  50. _strncpy  strncpy      ### name1         ### name2         ### name3
  51.                        ### name4 ...
  52.  
  53. The name1...name<n> are the places that refer to strncpy.  Somebody
  54. refers to it or it wouldn't be linked in.
  55.  
  56. If this doesn't fix the problem, it's possible that this is an lstat
  57. bug.  Again, contact technical support.
  58.  
  59. |> BTW, the program which is running 20X slower basically does this: some
  60. |> FGets() calls, a bit of processing to build a parse tree out of that
  61. |> data, and an execution of that parse tree.  The rough times I see are:
  62. |> 
  63. |>   Old 5.10b executable: 1 second
  64. |>   New 6.0 execeutable:  15 to 20 seconds
  65. |> 
  66. |>   - steve "confused" k
  67.  
  68. There is one possibility that showed up with the Hack Lite source while
  69. we were testing.  6.0 uses shared libraries for speed.  Sometimes 
  70. what happens on an A3000 or some other machine with a 68020 or
  71. higher is that all FAST memory gets used up by the compiler libraries,
  72. but since CHIP memory is still available, the system doesn't flush
  73. the libraries.  Try doing an AVAIL FLUSH command before running
  74. your program.  If it returns to its normal speed, you were out of
  75. FAST ram.
  76.  
  77. -- 
  78.   *****
  79. =*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
  80.  *|. o.| ||                                          1200/2400/9600 Dual
  81.   | o  |//     For all you do, this bug's for you!
  82.   ====== 
  83. usenet: walker@unx.sas.com                            bix: djwalker 
  84. Any opinions expressed are mine, not those of SAS Institute, Inc.
  85.  
  86.