From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: Unusual SAS6.0 results
Originator: walker@twix.unx.sas.com
Date: Mon, 16 Nov 1992 14:09:30 GMT
Organization: SAS Institute Inc.


In article <BxrwC8.3AG@fc.hp.com>, koren@fc.hp.com (Steve Koren) writes:
|> 2. GENPROTO mode crashes the machine a lot.  I get consistant crashes
|> on 2 out of 30 source files.  No big deal though; I can generate the
|> prototypes by hand.

We fixed a bug in GENPROTO for the upcoming 6.1 patch that may fix
your problem, but if you want to make sure it gets fixed, contact
technical support with a test case.  You can use the EMITS facility,
described in the "Getting Help" chapter of the User's Guide, to 
report the problem via email.

|> with the same speed.  However, the medium sized executable is not
|> so happy.  It runs as before, but it is *much* slower.  I'm talking
|> about 20X here.  It is getting no enforcer hits; I've checked that.  Since

No idea what is going on without source code or a runnable program to 
look at.  There is nothing in 6.0 that should have caused this.
For such a dramatic difference, there has to be something different
in the way the program is linked - different library functions,
different startup, something.

|> I really wanted to get it back to its old execution speed, I did a
|> lprof and lstat on it.  I'm getting _really_ wierd results.  Here is
|> the 1st few lines from the lstat output:
|> 
|>  95.4023%  95.4023%   f97c      249 _strncpy  <- I DON'T CALL THIS!
|>   0.7662%  96.1685%   7c58        2 @Read_String [lines 290-327 in Lexer.c]
|>   0.7662%  96.9349%   92d4        2 _yyparse [lines 966-1103 in Parser.y.C]

First, strncpy may be called by a library function that you call.
Use the MAP and MAPXREF options to generate a linker cross-reference
and see who is calling strncpy.  You'll find some lines in the cross-
reference like the following:

symbol   (Def) module  Off (Ref) Module  Off (Ref) Module  Off (Ref) Module  
_strncpy  strncpy      ### name1         ### name2         ### name3
                       ### name4 ...

The name1...name<n> are the places that refer to strncpy.  Somebody
refers to it or it wouldn't be linked in.

If this doesn't fix the problem, it's possible that this is an lstat
bug.  Again, contact technical support.

|> BTW, the program which is running 20X slower basically does this: some
|> FGets() calls, a bit of processing to build a parse tree out of that
|> data, and an execution of that parse tree.  The rough times I see are:
|> 
|>   Old 5.10b executable: 1 second
|>   New 6.0 execeutable:  15 to 20 seconds
|> 
|>   - steve "confused" k

There is one possibility that showed up with the Hack Lite source while
we were testing.  6.0 uses shared libraries for speed.  Sometimes 
what happens on an A3000 or some other machine with a 68020 or
higher is that all FAST memory gets used up by the compiler libraries,
but since CHIP memory is still available, the system doesn't flush
the libraries.  Try doing an AVAIL FLUSH command before running
your program.  If it returns to its normal speed, you were out of
FAST ram.

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.