Ron Roskens writes:
> Jason Thorpe writes:
> > In this case, it's not the performance of the NetBSD getgrent() that's in 
> > question.  It's worth noting that a native NetBSD ls(1) works peachy, but 
> > the HP-UX ls(1) has performance problems.  Now that I'm back from my 
> > Thanksgiving holiday, I'll be looking into it again.

> Actually the problem is inside the grscan() function. The problem lies in the
> fact that when it scans the YP group file it continually retransmits the whole
> database. Grscan doesn't take into account that when searching a YP database
> we don't need to scan the whole database, we can request a match. Or am I
> missunderstanding the yp_match() function?

No you're not misunderstanding, yp_match does as you suspect.

The entire backend to grscan() needs rewriting to take advantage of
yp_match on bygid/byname.

And what do you know, as part of my nsswitch implementation, I've
done that!  I'll have beta code for nsswitch available after 1.1
is released and I've merged my changes relative to that. And for those
who *don't* like nsswitch (you luddites! :), you can just have
"group: compat" and get the behaviour you want (but much faster due to
the reworked grscan())


> You won't notice much of a slow down until you start using a large YP group
> file. 1000 lines of data retransmitted for every file is a lot of extra
> overhead that can and needs to be avoided.

Funnily enough, I don't use yp for groups or passwd, just netgroups.
On our ULTRIX boxen we use Hesiod for passwd/group. It has 1K limits
on a single record, but at least you don't break on DBM limitations.

-- 
Luke Mewburn <luke.mewburn@itg.telstra.com.au>
"Aah ... Yes, and how does madam wish to pay?" She slapped her credit
 card on the counter. "Eventually."
                  -- Lady Sharrow, in Iain M. Banks' `Against a Dark Background'