[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8794: cons_to_long fixes; making 64-bit EMACS_INT the default
From: |
Stefan Monnier |
Subject: |
bug#8794: cons_to_long fixes; making 64-bit EMACS_INT the default |
Date: |
Mon, 06 Jun 2011 13:01:16 -0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
> 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
bug#8794: (a) straightforward prerequisite fixes, Paul Eggert, 2011/06/03
bug#8794: (b) make the 64bit-on-32bit the default (if supported), Paul Eggert, 2011/06/03
bug#8794: (c) fix the cons<->int conversions, Paul Eggert, 2011/06/03