Sender: nate AT cartsys DOT com
Message-ID: <35FAD365.A5A05345@cartsys.com>
Date: Sat, 12 Sep 1998 13:02:45 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: Tal Lavi <ranla AT post DOT tau DOT ac DOT il>, djgpp AT delorie DOT com
Subject: Re: MAJOR slowdowns in translating TP7 gfx code to DJGPP2: Suplement 2
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980910203626 DOT 10176F-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

> On Thu, 10 Sep 1998, Tal Lavi wrote:

> > I downloaded the bug fix for the profiler problem, but I had no idea about
> > what to do with it because of lack of documantation. I took the already built
> > libc file and was done with it.

That's fine, using the prebuilt libc *is* the easiest solution. 
However, I would like to make the documentation easy to understand. 
Could you explain what confused you?
 
> > I also took the libcpg.zip file. but how can I use it to profile libc
> > functions?
> 
> The easiest way is to replace your libc.a with libc_pg.a, and then relink
> your program.  (Actually, the linker should automatically link agains
> libc_pg.a when you link with -pg switch, but I don't think DJGPP is set
> that way by default, and I don't recommend that you mess with system
> files to set that up.)

Adding `-lc_pg' to the command line might work also.  Actually, you
might have to do
`-lc_pg -lgcc -lc_pg'.  Hmm... maybe just replacing libc.a is fine. :) 
(Be sure to make a backup!)

> Btw, I think you shouldn't be worried about profiling the library.
> Profile your code first, as most probably, the cause for the slow-down is
> in your code.

Agreed.
-- 

Nate Eldredge
nate AT cartsys DOT com