X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient:	djgpp-workers AT delorie DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:content-type;
	bh=2SuVjmbrxrPwAzzwqbnGMchZRxtTr/2NyEQIuo1X5Ws=;
	b=xAD9jzW7Q+hoKbJGRo02wrg+AD0w+qLWe4g1dlV6I2MNoFVky+odajpdgCI+4z8P5o
	9YzQJ/lf7Q3w4KUUuPwGG41R8nNpXd1YWN2nyc6w4GuuqHtibj5WWio5gfzptBWF5THs
	jh5wHUXEGkmNNb9p6+2G1e2MA87G1v/RfUJBMiK9mZoHyu2uKzhBCCR52HK2NwuzZ/de
	5Z7WVQ69Kqo/HeKmighnx7N3cuBH3OAG53iIAKuibzzdwOFvuhwvRCsbTxd6dR8gutwc
	hmx+qupn7oi3oGNjQ/eM5ZF6Oeg/jckNswqq3qxUHbjlhQE10RlMpK45xZ8HxaqkCBa9
	0pTw==
MIME-Version:	1.0
X-Received:	by 10.60.31.15 with SMTP id w15mr7860982oeh.0.1363892107009; Thu,
	21 Mar 2013 11:55:07 -0700 (PDT)
In-Reply-To:	<83d2usznat.fsf@gnu.org>
References:	<5140A042 DOT 9050805 AT iki DOT fi>
	<CAA2C=vB08rhgRyL-WX+vgXQKxkh4-bXxYZRG+8NyL1HzaUKafA AT mail DOT gmail DOT com>
	<CAA-ihx-wzMncQTikJZ2yFuSCzz4ebBUneNcm5iO4DygvL519aw AT mail DOT gmail DOT com>
	<CAA2C=vAk6h+ko+RRgnp-JXX68G1cJKxGxp=ACQCNcdZcBymgQw AT mail DOT gmail DOT com>
	<83d2usznat DOT fsf AT gnu DOT org>
Date:	Thu, 21 Mar 2013 13:55:06 -0500
Message-ID:	<CAA-ihx9G73RGqtWcGJmGjsn0LeRhgcLdcmyy2TavYEH6_V06Fw@mail.gmail.com>
Subject:	Re: About new DJGPP v2.04 beta
From:	Rugxulo <rugxulo AT gmail DOT com>
To:	djgpp-workers AT delorie DOT com
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Hi,

On Thu, Mar 21, 2013 at 12:15 PM, Eli Zaretskii <eliz AT gnu DOT org> wrote:
>>
> how much longer does it take 'find' to traverse a given tree,
> when compiled with 2.04 vs 2.03?

You'd have to recompile both of them with the same (latest?) compiler.
They most assuredly use older GCCs, which may or may not be worse on
your given cpu, esp. using our default "-mtune=pentium". BTW, they're
already noticeably slower than native DOS tools for similar
functionality.

Alright, lemme reboot and try it (with stock builds) anyways, but I'm
skeptical ... both of these builds are from June 2008, so caveat
emptor (as I'm running on a Core i5). I guess that's level enough of a
playing field.

N.B. Please don't read too much into this, it could be a combination
of factors or something else. It's not wrong to guess that it's the
libc symlink searches, but we don't know for sure just yet.

"time find /mnt/sda3" in PuppyLinux takes < 1 sec.  (probably already
pre-read the FAT at bootup)

"dir /s/b c:\zips" in FreeDOS (with FreeCOM shell) is 5 secs.

With my normal DOS setup, e.g. everything loaded (including UIDE for
software cache and Ultra DMA, but no slow DOSLFN), I get this (and ran
CC.COM to "clear cache" between runs):

"redir -t current /zips" = Elapsed time: 7.250 seconds
"redir -t beta /zips" = Elapsed time: 12.750 seconds

(Similar timing with FreeDOS' runtime.com excised for brevity)

"redir -t current /zips -ls" = Elapsed time: 17.520 seconds
"redir -t beta /zips -ls" = Elapsed time: 33.500 seconds

Totally clean (F5) FreeDOS boot (no drivers or TSRs loaded):

"redir -t current /zips" = Elapsed time: 44.380 seconds
"redir -t beta /zips" = Elapsed time: 142.970 seconds (0:02:22.970)

- Raw text -