From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Multibyte and unibyte file names Date: Sun, 27 Jan 2013 02:57:58 +0900 Message-ID: <87k3qz3jyx.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83ehhbn680.fsf@gnu.org> <83wqv2ldk1.fsf@gnu.org> <83obgel94c.fsf@gnu.org> <83k3r1lnlb.fsf@gnu.org> <83vcalj97s.fsf@gnu.org> <87vcak3ar1.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1359223090 20345 80.91.229.3 (26 Jan 2013 17:58:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jan 2013 17:58:10 +0000 (UTC) Cc: eliz@gnu.org, kzhr@d1.dion.ne.jp, michael.albinus@gmx.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 26 18:58:29 2013 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 1TzA1L-0000zq-OK for ged-emacs-devel@m.gmane.org; Sat, 26 Jan 2013 18:58:27 +0100 Original-Received: from localhost ([::1]:58627 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TzA14-0002H7-4j for ged-emacs-devel@m.gmane.org; Sat, 26 Jan 2013 12:58:10 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TzA11-0002Gr-HH for emacs-devel@gnu.org; Sat, 26 Jan 2013 12:58:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TzA10-0006wL-Fw for emacs-devel@gnu.org; Sat, 26 Jan 2013 12:58:07 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:51833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TzA0v-0006vO-II; Sat, 26 Jan 2013 12:58:01 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id B52D59708E6; Sun, 27 Jan 2013 02:57:58 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 776B71A293C; Sun, 27 Jan 2013 02:57:58 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:156661 Archived-At: Richard Stallman writes: > Removing unibyte mode could probably be a big slowdown for visiting > binary files, This was benchmarked for XEmacs in the early 2000s, and for files big enough to matter the decoding time is swamped by disk I/O. If it's possible to mmap files into buffers, the difference to visiting might be perceptible, but even SSDs can't transfer fast enough to beat CPUs at decoding if you actually fill the buffer. The biggest difference would be in `goto-char', which becomes O(distance from the nearest point in the position cache). It would be possible to initialize the cache at read time, and a cache 1% of the size of the file would allow you to cache a position every 2KB or so, for effectively O(1) performance.[1] We never implemented that, though; the most important uses for large files were log files, and all of the people who were using Emacsen to read log files had pure ASCII files which did allow random access. > and might make it unreliable. Depends on how you implement it. XEmacs's implementation has never had a bug that I've heard of. Footnotes: [1] Since you know the cache is "nearly uniform", you can do better than O(log(0.0005*size)).