> "Richard" == Richard M Stallman <[EMAIL PROTECTED]> writes:
> I'd had already suggested a change to grow gc-cons-threshold as the heap
> grows (a long time ago), and I see that XEmacs's gc-cons-percentage is
> clean interface to such a feature. I think we should introduce this
>
I'd had already suggested a change to grow gc-cons-threshold as the heap
grows (a long time ago), and I see that XEmacs's gc-cons-percentage is
clean interface to such a feature. I think we should introduce this
variable and give it a good non-zero default value.
I agree. Would y
> think, but then again it might not: IIRC, Emacs always does a GC
> before it asks the OS for more heap. So you might see the message
I don't think this is true. GC should only ever be called from eval
or funcall. Several parts of the code assume that Fcons cannot call the GC,
for example.
In
> Garbage collection will happen if this percentage of the total amount of
> memory used for data has been allocated since the last garbage collection.
We talked about a percentage of the installed physical memory, not of
memory used for data.
I did not n
> To say nothing of the fact that it has a semantics different from what
> we thought to implement:
>
>> Garbage collection will happen if this percentage of the total amount of
>> memory used for data has been allocated since the last garbage collection.
>
> We talked about
So, gc-cons-threshold serves as the lower bound, and
gc-cons-percentage itself is the upper.
I think I see a misunderstanding here about the meaning of upper
limit. This doc string does not suggest there is any upper limit.
We could implement this feature, and add our own upper limit,
pe
> From: Adrian Aichner <[EMAIL PROTECTED]>
> Date: Sun, 26 Jun 2005 10:20:52 +0200
> Cc: Adrian Aichner <[EMAIL PROTECTED]>, emacs-devel@gnu.org, [EMAIL PROTECTED]
>
> Oops, this feature not currently enabled in XEmacs!
To say nothing of the fact that it has a semantics different from what
we tho
Miles Bader <[EMAIL PROTECTED]> writes:
> On 6/26/05, Adrian Aichner <[EMAIL PROTECTED]> wrote:
>> >> isn't that the purpose of
>> >> gc-cons-percentage
>> >
>> > There is no such variable in Emacs.
>>
>> Oh, so it's a XEmacs-only thing.
>
> OK; guess if we add this feature, we should use the sam
On 6/26/05, Adrian Aichner <[EMAIL PROTECTED]> wrote:
> >> isn't that the purpose of
> >> gc-cons-percentage
> >
> > There is no such variable in Emacs.
>
> Oh, so it's a XEmacs-only thing.
OK; guess if we add this feature, we should use the same variable name though.
As Gaëtan Leurent pointed o
Miles Bader <[EMAIL PROTECTED]> writes:
> On 6/25/05, Adrian Aichner <[EMAIL PROTECTED]> wrote:
>> > For example,
>> > the default value could be dependent on the amount of installed
>> > memory.
>>
>> isn't that the purpose of
>> gc-cons-percentage
>
> There is no such variable in Emacs.
Oh, so
Yes I think that would be a good idea. Setting the cons-threshold to
say 1 or 2% of RAM size would yield roughly the numbers which are
being recommended (at 1%, you'd get 640K on a 64MB system, and 5MB on
a 512MB system).
Getting that number is system-dependent of course, but
> Date: Sat, 25 Jun 2005 21:15:19 +0900
> From: Miles Bader <[EMAIL PROTECTED]>
> Cc: Juri Linkov <[EMAIL PROTECTED]>, emacs-devel@gnu.org
>
> Getting that number is system-dependent of course, but there seems no
> reason not to do it on systems where someone wants to write the code
> (it can even
> Cc: [EMAIL PROTECTED], Eli Zaretskii <[EMAIL PROTECTED]>, Juri Linkov <[EMAIL
> PROTECTED]>,
> emacs-devel@gnu.org
> From: [EMAIL PROTECTED] (=?iso-8859-1?Q?Ga=EBtan?= LEURENT)
> Date: Sat, 25 Jun 2005 15:10:49 +0200
>
>
> Miles Bader wrote on 25 Jun 2005 14:15:19 +0200:
>
> > Yes I t
Miles Bader wrote on 25 Jun 2005 14:15:19 +0200:
> Yes I think that would be a good idea. Setting the cons-threshold to
> say 1 or 2% of RAM size would yield roughly the numbers which are
> being recommended (at 1%, you'd get 640K on a 64MB system, and 5MB on
> a 512MB system).
This is maybe no
On 6/25/05, Adrian Aichner <[EMAIL PROTECTED]> wrote:
> > For example,
> > the default value could be dependent on the amount of installed
> > memory.
>
> isn't that the purpose of
> gc-cons-percentage
There is no such variable in Emacs.
-Miles
--
Do not taunt Happy Fun Ball.
On 6/25/05, Eli Zaretskii <[EMAIL PROTECTED]> wrote:
> If we find that my experience of yore is no longer relevant, I agree.
> But then we should probably modify the default of the threshold
> accordingly, instead of telling users to mess with it. For example,
> the default value could be dependen
Eli Zaretskii <[EMAIL PROTECTED]> writes:
> If we find that my experience of yore is no longer relevant, I agree.
> But then we should probably modify the default of the threshold
> accordingly, instead of telling users to mess with it. For example,
> the default value could be dependent on the a
> From: Juri Linkov <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
> Date: Sat, 25 Jun 2005 00:54:05 +0300
>
> >> It helps to increase the value of gc-cons-threshold at least tenfolds
> >> to run slow GC less often.
> >
> > Yes, but then Emacs itself slows down
On 6/25/05, Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> Well, obviously if you have very little resident memory and set
> gc-cons-threshold to a huge value, then conceivably your operating
> system could wind up spending most of its time swapping memory. Then
> not only Emacs, but everything else a
Juri Linkov wrote:
In my tests, when I have the default gc-cons-threshold set to 40,
GC takes 1 sec. When I increase it 100 times to 4000, GC takes
the same 1 sec (and not 100 sec as if there were linear dependence).
And there is no slowdown.
Increasing gc-cons-threshold by a
>> It helps to increase the value of gc-cons-threshold at least tenfolds
>> to run slow GC less often.
>
> Yes, but then Emacs itself slows down, and when GC eventually
> happens, it, too, takes a very long time.
In my tests, when I have the default gc-cons-threshold set to 40,
GC takes 1 sec.
> From: Juri Linkov <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
> Date: Fri, 24 Jun 2005 22:02:52 +0300
>
> >> I noticed too that in sufficiently long Emacs sessions Lisp
> >> evaluation slows down.
> >
> > One possible situation where this could happen is i
22 matches
Mail list logo
