Received: with ECARTIS (v1.0.0; list gopher);
 Thu, 04 Apr 2002 18:20:04 -0500 (EST)
Return-Path: <jgoerzen@complete.org>
Delivered-To: gopher@complete.org
Received: from christoph.complete.org (pcp947166pcs.cstltn01.in.comcast.net
 [68.58.145.248])
	by pi.glockenspiel.complete.org (Postfix) with ESMTP id ADEFD3B81B
	for <gopher@complete.org>; Thu,  4 Apr 2002 18:20:03 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by christoph.complete.org (Postfix) with ESMTP id B9E895A40A
	for <gopher@complete.org>; Thu,  4 Apr 2002 18:20:03 -0500 (EST)
Date: Thu, 4 Apr 2002 18:20:03 -0500
Subject: [gopher] Re: Pygopherd nearing gopherd replacement
Content-type: text/plain; charset=US-ASCII
Mime-Version: 1.0 (Apple Message framework v481)
From: John Goerzen <jgoerzen@complete.org>
To: gopher@complete.org
Content-Transfer-Encoding: 8bit
In-Reply-To: <p05010412b8d273621bed@[205.189.158.32]>
Message-Id: <7DFACC96-4822-11D6-857D-0003930BF072@complete.org>
X-Mailer: Apple Mail (2.481)
X-archive-position: 555
X-ecartis-version: Ecartis v1.0.0
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
X-original-sender: jgoerzen@complete.org
Precedence: bulk
Reply-to: gopher@complete.org
List-help: <mailto:ecartis@complete.org?Subject=help>
List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-ID: Gopher <gopher.complete.org>
X-List-ID: Gopher <gopher.complete.org>
List-subscribe: <mailto:gopher-request@complete.org?Subject=subscribe>
List-owner: <mailto:jgoerzen@complete.org>
List-post: <mailto:gopher@complete.org>
List-archive: <http://www.complete.org/mailinglists/archives/>
X-list: gopher


On Thursday, April 4, 2002, at 04:19  PM, Robert Hahn wrote:

> You want comments?
>
> I've a question. does that count? :)

Sure :-)

> How fast is it relative to the C version?

Right now, there has been exactly zero effort expended on optimization.
I have also not done any formal benchmarks.

That said, there is no noticeable difference between pygopherd and 
gopherd except when rendering very large (hundreds or thousands of 
items) UMN-style (dynamically-generated) directories.  Part of this is 
because pygopherd does more work to generate a directory -- looking up 
MIME types and such.  Part of this is because there is no caching 
mechanism yet.  And part of it is probably due to the modular 
architecture and interpreted nature of the code.  Maybe I've just done 
something inefficiently, too.

I was quite encouraged by the results otherwise.  The server generates 
"sane" URLs -- in fact, you could make it listen on port 80 and it would 
be indistinguishable from a regular webserver.  HTTP URLs generated by 
pygopherd do not contain a type character, so relative links in HTML 
docs will work, at least over HTTP (and perhaps with non-web-browser 
Gopher implementations?  crossing fingers!)  Pygopherd also does not add 
an extra (or "second" if you're using URLs) type character like UMN 
gopherd does.  Because it figures all this out itself, that is 
unnecessary.

> My guess is that the main bottleneck is the disk access, so it's
> probably not much slower, right?

Probably the main bottleneck is the Internet, followed by disk.  Yes.

-- John