Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!mcsun!ukc!edcastle!hwcs!zen!frank
From: frank@zen.co.uk (Frank Wales)
Newsgroups: comp.sys.hp
Subject: HP-UX s800 xdb question
Keywords: sloooow
Message-ID: <1728@zen.co.uk>
Date: 11 Oct 89 17:47:47 GMT
Organization: Zengrange Limited, Leeds, England
Lines: 53

Okay, HP, I give in.  This problem's been annoying me for some time,
and was logged as a bug in s800 HP-UX 3.01 (and is still in 3.1), but
my curiosity as to its cause has got the better of me.

xdb(1) takes a *long* time single-stepping the return of a large
structure.  Here is the example program I sent to our Customer Response
Centre (instructions start in main's comment block):

xdbslow.c:

  /* big structure to pass around...also try it as:
   *
   * struct big {char Message[1024];}
   *
   * Decide what you think should happen beforehand.
   */
  struct big {enum {A,B,C} Class; char Message[1024];}
  foo()
  {
    struct big a;  /* uninitialised, but who cares? */
    /* ...now, try bu, followed by c, and note the speed;
     * ...then try bx, followed by c, and note the speed;
     * ...finally, try s, then go for a coffee...  */
    return a;
  }

  main()
  {
    struct big b;
    /* First time here, type S to macro-step this function call;
     * note the time it takes.  Then, on each subsequent
     * pass, type s to step through the whole function...
     * [further instructions in foo()] */
    b=foo();
    return 0;
  }

Compile with `cc -g xdbslow.c'.  Enter xdb and follow the instructions
in the comments, noting the execution time of s when stepping over the
return statement in foo().

My question is simply: why does this happen?  [And is there a tweak I
can apply *now* to get rid of it? ;-)]

[By the way, why are the "Procedures:" and "Files:" counts presented on
xdb entry both one too large under 3.1?  (They were the *same number*
under 3.01, so at least that got fixed :-).)  Are they counting
the startup module that gets linked in?  Whyever (sp!) they are too large,
is it documented?  Just curious.]
--
Frank Wales, Systems Manager,        [frank@zen.co.uk<->mcvax!zen.co.uk!frank]
Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217