9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Peter Schay <pschay@pobox.com>
To: 9fans@cse.psu.edu
Subject: [9fans] env walk
Date: Wed,  9 May 2001 11:54:30 +0000	[thread overview]
Message-ID: <3AF92776.18AE2A42@pobox.com> (raw)

This posting got truncated at the ".".  2nd attempt:

Here's more on the performance subject; I hope the
following optimization is useful and not too inelegant.

The algorithm for walking in #e seems to be O(n*n).
I think it's pretty easy to make it O(n).

For example, on my system the following script takes no
time with 42 environment variables takes 4 seconds with
441 vars:

	term% time /fd/0 <<.
	#!/bin/rc
	rfork e
	eval X^(`{seq 1})^('=1')
	echo nvars `{ls /env | wc -l}
	.
	nvars 42
	0.01u 0.02s 0.06r        /fd/0

	term% time /fd/0 <<.
	#!/bin/rc
	rfork e
	eval X^(`{seq 400})^('=1')
	echo nvars `{ls /env | wc -l}
	.
	nvars 441
	0.14u 3.59s 4.14r        /fd/0

(OK, this was an abusive script.  But the effect can be
noticable for non-abusers too.)

Usually you really only lose time when rc forks, I think,
and even then not always.  I'm not exactly sure.

Changing envwalk() has a big impact on large (ok, bloated)
make projects.  Even on the small job of compiling the
Plan 9 kernel you save a few per cent of system time.  And I'm
sure there are many truly abusive projects out there that
could build much faster.

IMHO, rc and mk are masterpieces and it's a shame
to limit them by wasting time on walks in #e.

So here's a proposed optimization of envwalk(), to avoid
spending too much time in envgen():

term% diff /sys/src/9/port/devenv.c .
60c60,78
<       return devwalk(c, name, 0, 0, envgen);
---
>       Evalue *e;
>       Egrp *eg = up->egrp;
> 
>       isdir(c);
>       if(name[0]=='.' && name[1]==0)
>               return 1;
> 
>       qlock(eg);
>       for(e = eg->entries; e; e = e->link)
>               if(!strcmp(e->name, name))
>                       break;
>       if(e) {
>               c->qid = e->qid;
>               qunlock(eg);
>               return 1;
>       }
>       qunlock(eg);
>       strncpy(up->error, Enonexist, NAMELEN);
>       return 0;
\x01\x01\x01\x01


             reply	other threads:[~2001-05-09 11:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-09 11:54 Peter Schay [this message]
2001-05-09 13:23 presotto
2001-05-09 15:45 ` Peter Schay
2001-05-09 16:58 presotto
2001-05-09 17:34 ` Sam
2001-05-09 17:39   ` Sam
2001-05-10  8:33 ` Peter Schay
2001-05-10 12:58 presotto
2001-05-10 13:04 presotto
2001-05-10 13:39 rog
2001-05-10 13:49 rob pike
2001-05-10 14:41 presotto
2001-05-10 14:48 rog

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3AF92776.18AE2A42@pobox.com \
    --to=pschay@pobox.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).