From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#8794: cons_to_long fixes; making 64-bit EMACS_INT the default Date: Mon, 06 Jun 2011 13:01:16 -0300 Message-ID: References: <4DE89EB8.9020202@cs.ucla.edu> <4DE935F6.2080802@cs.ucla.edu> <4DEC9227.5060000@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1307382757 13781 80.91.229.12 (6 Jun 2011 17:52:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Jun 2011 17:52:37 +0000 (UTC) Cc: 8794@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 06 19:52:30 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QTdyW-0005k7-EC for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jun 2011 19:52:28 +0200 Original-Received: from localhost ([::1]:45602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTdyU-00016V-VV for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jun 2011 13:52:27 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTcFh-0004xp-OO for bug-gnu-emacs@gnu.org; Mon, 06 Jun 2011 12:02:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTcFe-0008Dl-Vh for bug-gnu-emacs@gnu.org; Mon, 06 Jun 2011 12:02:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTcFe-0008Db-Kx for bug-gnu-emacs@gnu.org; Mon, 06 Jun 2011 12:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QTcFd-0002TJ-TD; Mon, 06 Jun 2011 12:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jun 2011 16:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8794 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8794-submit@debbugs.gnu.org id=B8794.13073760969470 (code B ref 8794); Mon, 06 Jun 2011 16:02:01 +0000 Original-Received: (at 8794) by debbugs.gnu.org; 6 Jun 2011 16:01:36 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QTcF8-0002Sb-4A for submit@debbugs.gnu.org; Mon, 06 Jun 2011 12:01:36 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QTcF5-0002SM-TT for 8794@debbugs.gnu.org; Mon, 06 Jun 2011 12:01:28 -0400 Original-Received: from 213-159-126-200.fibertel.com.ar ([200.126.159.213]:39469 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QTcEz-0001Kw-4k; Mon, 06 Jun 2011 12:01:21 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 01F8866189; Mon, 6 Jun 2011 13:01:16 -0300 (ART) In-Reply-To: <4DEC9227.5060000@cs.ucla.edu> (Paul Eggert's message of "Mon, 06 Jun 2011 01:39:03 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 06 Jun 2011 12:02:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:47006 Archived-At: > What else needs to be done before it's reasonable to install > something like (b)? Experience with it. AFAIK a non-negligible fraction of users would be happy to see such a feature because they need to access large files that don't grow too fast (i.e. large but still within the 32bit limit) but: - this category of files is fairly small: only files between 512MB and 2GB, basically. So a non-negligible fraction of those users may end up finding out that it only covers some percentage of their needs because the other files go beyond the 2GB limit. - some other percentage of those users won't be satisfied either because such large files may prove too slow to access. - so given the limited benefits, I want to make sure the drawbacks are negligible. How is the memory use impacted by your change in "typical" sessions? How is the CPU use impacted in typical sessions? Benchmarks running the byte-compiler, Gnus, and any other intensive Elisp code would be welcome. Benchmarks testing the impact on redisplay performance wold also be welcome. I'd hope most of those benchmarks to show very little difference, but so far I haven't seen any reports to make confident that this is the case. Stefan