From owner-freebsd-current@FreeBSD.ORG  Thu Jul  8 22:50:15 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9D97016A4CE; Thu,  8 Jul 2004 22:50:15 +0000 (GMT)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 815CA43D4C; Thu,  8 Jul 2004 22:50:15 +0000 (GMT)
	(envelope-from bright@elvis.mu.org)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id 71AB35C841; Thu,  8 Jul 2004 15:50:15 -0700 (PDT)
Date: Thu, 8 Jul 2004 15:50:15 -0700
From: Alfred Perlstein <alfred@freebsd.org>
To: Dag-Erling Sm?rgrav <des@des.no>
Message-ID: <20040708225015.GR95729@elvis.mu.org>
References: <20040707124751.GA66588@orion.daedalusnetworks.priv>
	<xzpwu1e3zpb.fsf@dwp.des.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <xzpwu1e3zpb.fsf@dwp.des.no>
User-Agent: Mutt/1.4.2.1i
cc: Giorgos Keramidas <keramida@freebsd.org>
cc: current@freebsd.org
Subject: Re: RFC: Sorting in top -m io
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jul 2004 22:50:15 -0000

* Dag-Erling Sm?rgrav <des@des.no> [040708 15:24] wrote:
> Giorgos Keramidas <keramida@freebsd.org> writes:
> > What do you all think of this patch to top(1)?
> 
> extremely inefficient; get_io_stats() is an expensive function and you
> really don't want to call it approximately log(n) per process while
> sorting, especially when it returns the same values every time.
>
> an ugly trick to get around this is to have get_process_info() store
> io stats in ki_spare[] or some other unused kinfo_proc field, so you
> never need to call get_io_stats() outside get_process_info().

I think you could generate an array indexed by the offset into
the procs feild...  If that's not clear I may be able to whip
up a cache of that info tonight for you.  (instead of
spamming a feild in the array.)

> you should also do secondary sort orders like the existing compare_*()
> functions do, since qsort() is unstable, so processes with identical
> stats will jump around if they aren't also sorted by name or some
> other secondary criterion.

You can use mergesort, but I may be missing the point.

-- 
- Alfred Perlstein
- Research Engineering Development Inc.
- email: bright@mu.org cell: 408-480-4684