From owner-freebsd-hackers  Wed Feb  1 13:15:33 1995
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA07125 for hackers-outgoing; Wed, 1 Feb 1995 13:15:33 -0800
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id NAA07118; Wed, 1 Feb 1995 13:15:23 -0800
Received: by cs.weber.edu (4.1/SMI-4.1.1)
	id AA08106; Wed, 1 Feb 95 14:08:42 MST
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9502012108.AA08106@cs.weber.edu>
Subject: Re: Optimizing CVS?
To: bde@zeta.org.au (Bruce Evans)
Date: Wed, 1 Feb 95 14:08:41 MST
Cc: jkh@freefall.cdrom.com, roberto@blaise.ibp.fr, hackers@freefall.cdrom.com
In-Reply-To: <199502011625.DAA17258@godzilla.zeta.org.au> from "Bruce Evans" at Feb 2, 95 03:25:46 am
X-Mailer: ELM [version 2.4dev PL52]
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> >Maybe we should optimize stat(2) before... Ask Remy about the tests
> >he made between ext2fs and our ffs. Our stat(2) is way slower than the
> >1.1.5.1 one.
> 
> Actual testing shows that stat() is slightly faster under
> FreeBSD-current than under linux-1.1.36 for files in a medium sized
> directory, and 5 times faster under FreeBSD for files in a large
> directory!  FreeBSD is much slower at creating the files to be stat()ed
> because it updates metadata synchronously.

This is a bogus benchmark; you are hitting pages that are cached by
virtue of the number of reps applied and the operation order.

This does not show the speed loss is not in the stat in practice.

In effect, you are testing system call + copyout time rather than system
call + fetch + copyout time.

This is the same type of reasoning that make Larry McVoy's lmbench
mmap benchmark (map-but-don't-use) bogus.

This is also the same type of thing that has UnixWare claiming 20 mic's
for a system call.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.