X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: Rugxulo <rugxulo AT gmail DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: gprof output
Date: Sat, 26 May 2012 13:46:51 -0700 (PDT)
Organization: http://groups.google.com
Lines: 24
Message-ID: <99bf0561-8756-4138-92aa-6b25499f1c57@h41g2000yqm.googlegroups.com>
References: <7822bb4a-1059-491a-8489-e1d9f3dbc501 AT l17g2000vbj DOT googlegroups DOT com>
NNTP-Posting-Host: 65.13.115.246
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: posting.google.com 1338065211 877 127.0.0.1 (26 May 2012 20:46:51 GMT)
X-Complaints-To: groups-abuse AT google DOT com
NNTP-Posting-Date: Sat, 26 May 2012 20:46:51 +0000 (UTC)
Complaints-To: groups-abuse AT google DOT com
Injection-Info: h41g2000yqm.googlegroups.com; posting-host=65.13.115.246; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16
 (KHTML, like Gecko) Chrome/10.0.630.0 Safari/534.16,gzip(gfe)
Bytes: 2084
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q4QL028Z014378
Reply-To: djgpp AT delorie DOT com

Hi,

On May 26, 1:34 pm, Georg <dos DOT  DOT  DOT  AT googlemail DOT com> wrote:
>
> I tried gprof to profile one of my programs. This is the ouput:

I'm no expert, not really used gprof (esp. lately, I actually thought
it didn't work on DJGPP anymore).

> My question is: is it normal that a djgpp program uses 87% for
> __dpmi_int? If not, what could be done to reduce this?

Yes, it's normal for __dpmi_int to be called a lot, but how much
overall is "ideal" I don't know.

Try increasing the transfer buffer to 32k, esp. if doing heavy file
accesses. And/or try to lump __dpmi_int calls together at start of
program outside main loop (if any), if the results don't change over
time.

I don't know what else can be done to minimize it. Perhaps writing
directly to screen/video memory (nearptr??) would be faster? Otherwise
you might have to tweak the libc or use different (but equivalent)
functions.