GNU bug report logs - #8794
cons_to_long fixes; making 64-bit EMACS_INT the default

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 8794 <at> debbugs.gnu.org
Subject: bug#8794: cons_to_long fixes; making 64-bit EMACS_INT the default
Date: Mon, 06 Jun 2011 13:01:16 -0300

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.