From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: On being web-friendly and why info must die Date: Mon, 08 Dec 2014 23:29:42 -0800 Organization: UCLA Computer Science Department Message-ID: <5486A4E6.4040401@cs.ucla.edu> References: <20141205123549.GA29331@thyrsus.com> <2815659.zRQ0WWWeRr@descartes> <20141205175810.GD3120@thyrsus.com> <87lhmlncb1.fsf@earlgrey.lan> <20141205193643.GB5067@thyrsus.com> <87tx19rd1b.fsf@fencepost.gnu.org> <20141205215138.GF7784@thyrsus.com> <54823617.4000406@cs.ucla.edu> <83k325195l.fsf@gnu.org> <5482D94B.2070102@cs.ucla.edu> <5484FF31.5010808@cs.ucla.edu> <5485FC59.5030700@cs.ucla.edu> <87388p6glt.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1418110234 16331 80.91.229.3 (9 Dec 2014 07:30:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Dec 2014 07:30:34 +0000 (UTC) Cc: esr@thyrsus.com, emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 09 08:30:27 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XyFFZ-0008SQ-Dx for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2014 08:30:25 +0100 Original-Received: from localhost ([::1]:38214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyFFZ-0007MU-0i for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2014 02:30:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyFFA-0007Hc-IH for emacs-devel@gnu.org; Tue, 09 Dec 2014 02:30:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XyFF3-00014K-2u for emacs-devel@gnu.org; Tue, 09 Dec 2014 02:30:00 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:40782) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyFF2-000147-So for emacs-devel@gnu.org; Tue, 09 Dec 2014 02:29:52 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 0DA0CA60055; Mon, 8 Dec 2014 23:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbeMc7KxNdds; Mon, 8 Dec 2014 23:29:42 -0800 (PST) Original-Received: from [192.168.1.9] (pool-71-177-17-123.lsanca.dsl-w.verizon.net [71.177.17.123]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 484D8A6003E; Mon, 8 Dec 2014 23:29:42 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 In-Reply-To: <87388p6glt.fsf@engster.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:179528 Archived-At: David Engster wrote: > ~/git-2.2.0/Documentation> time asciidoc -b html user-manual.txt > asciidoc -b html user-manual.txt 7.26s user 0.02s system 90% cpu 8.068 total > > That's for 4.5k lines. > > ~/emacs/doc/misc> time makeinfo --html gnus.texi > makeinfo --html gnus.texi 2.00s user 0.04s system 85% cpu 2.385 total > > That's for 30k lines. Yes, that's texinfo4, of course That's a bit unfair to Texinfo, since gnus.texi @includes other files, and one should count all its input lines. Conversely, Texinfo 4 is no longer maintained and misses some useful new features, so one should measure Texinfo 5, which is waaayyy slooower. Furthermore, the (newer) asciidoctor is an order of magnitude faster than the (older) asciidoc, and it's not entirely fair to be using the way-slower variant in a benchmark. So overall I'm afraid the above numbers don't mean all that much.