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