From: gpt20 AT thor DOT cam DOT ac DOT uk (G.P. Tootell)
Newsgroups: comp.os.msdos.djgpp
Subject: profiling under djgpp
Date: 16 Jan 1997 17:33:03 GMT
Organization: University of Cambridge, England
Lines: 26
Sender: gpt20 AT hammer DOT thor DOT cam DOT ac DOT uk (G.P. Tootell)
Message-ID: <5bloof$k5d@lyra.csx.cam.ac.uk>
NNTP-Posting-Host: hammer.thor.cam.ac.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

ok, having just read section 13 of the faq again i can't find what i'm looking
for so i'm asking here :)

the program i'm profiling has a number of bottlenecks, mostly in one routine.
however the routine in question doesn't show up on the profile as being extensive
enough to be listed (in fact it says the %time spent on it was 0 which is quite
blatantly wrong :( i suspect this is because the time spent on it was relatively
small compared to that of dpmi_int and so it was scaled to 0. now the faq says
dpmi_int is for i/o and real mode services. what exactly does this cover? there's
no i/o going on that i'm aware of except for writing to the video screen and
shouldn't be any real mode services. it's basically just a lot of floating point
maths followed by some writing to screen. can i not tell the profiler to ignore
dpmi_int? or at least tell me *where* in the code these dpmi_ints are going on so
i can remove them? also can i profile parts of a function, ie. to refine the
profile and hence determine which part of the routine is slowest (eg. i know
routine_a() takes up too much time, can i set a breakpoint here to split the
routine in two? or do i have to
split it into 2 separate routines before it will profile this way?)
dj_movedata or something similar takes up some considerable time too. again i
don't know what's causing this to be able to rectify the problem :(

regards,
nik


--