> Actually, it often happens that things like ENABLE_CHECKING add assert
> statements in the macro expansion which causes the args to be used more
> than once.
> As far as I can see, ENABLE_CHECKING has no such effect anywhere.
It does.
See the definition of XSET:
#define XSET(var, t
Actually, it often happens that things like ENABLE_CHECKING add assert
statements in the macro expansion which causes the args to be used more
than once.
As far as I can see, ENABLE_CHECKING has no such effect anywhere.
And there is only one definition of SREF.
__
> Isn't it better to avoid using something like "offset++" as
> an argument of a macro even if we know that it's currently
> safe.
> I see no danger in it--most of our macros are safe, and we keep them
> that way.
Actually, it often happens that things like ENABLE_CHECKING add assert
s
Isn't it better to avoid using something like "offset++" as
an argument of a macro even if we know that it's currently
safe.
I see no danger in it--most of our macros are safe, and we keep them
that way. If you think it would be cleaner to rewrite that, I don't
mind if you do. But th
In article <[EMAIL PROTECTED]>, "Richard M. Stallman" <[EMAIL PROTECTED]>
writes:
>> I think that the cleanest thing to do, in loops that don't need to be
>> as fast as possible, is avoid saving addresses of string data at all.
> I agree. But, I think display_mode_element is the place
>
> I think that the cleanest thing to do, in loops that don't need to be
> as fast as possible, is avoid saving addresses of string data at all.
I agree. But, I think display_mode_element is the place
that have to be as fast as possible.
I would think that it doesn't take up very
In article <[EMAIL PROTECTED]>, "Richard M. Stallman" <[EMAIL PROTECTED]>
writes:
> I think that the cleanest thing to do, in loops that don't need to be
> as fast as possible, is avoid saving addresses of string data at all.
I agree. But, I think display_mode_element is the place
that have to
I think that the cleanest thing to do, in loops that don't need to be
as fast as possible, is avoid saving addresses of string data at all.
I suspect that compose_chars_in_text does not need to be as fast as
possible. Handa, do you think it does?
___
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Kim F. Storm) writes:
> The following code in compose_chars_in_text looks suspicious:
That's right. But, it's not used anymore and it seems that
I just forgot to delete that function. :-(
I'm sorry for taking your time on it. I've just deleted
HAR_POS_ADDR (start);
}
else
{
start++;
ptr += len;
>>>> if string is non-nil, and call4 did GC, then ptr may no longer
>>>> point into "string".
orarily changes gc_cons_threshold to prevent
> GC from occurring. It was broken and caused an infinite recursion.
I thought I had carefully updated it to change
gc_cons_combined_threshold instead.
> I think this is the clean fix.
OK.
> The slowdown is surely insignificant.
I'd expect i
gc_cons_threshold to prevent
GC from occurring. It was broken and caused an infinite recursion.
I think this is the clean fix.
The slowdown is surely insignificant.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Regardnig the change below:
2005-07-23 Richard M. Stallman <[EMAIL PROTECTED]>
* insdel.c (syms_of_insdel): staticpro combine_after_change_buffer.
* bytecode.c (MAYBE_GC): Test gc_cons_threshold and
gc_relative_threshold, one by one.
* keyboard.c (read_char
>>>>> "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
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 agr
> 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,
> 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
^^
> We talked about a percentage of the installed physical memory, not of
> memory used for data.
The semantics used by xemacs seems reasonable. The speed of GC
depends on memory used for Lisp data, not on the total physical memory.
With the growth of Lisp data, GC becomes m
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
> 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'
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 s
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
>&g
big server
with a lot a memory and a lot of users (my emacs is running on a server
with 8Gb of RAM -- 66 users are currently using it --, but wasting 80Mo
between each GC doesn't seem very smart)
We could put a cap on the default made this way, of no more
than 10mb, say. Or we could use
> 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
; with 8Gb of RAM -- 66 users are currently using it --, but wasting 80Mo
> between each GC doesn't seem very smart)
The default value of the GC threshold should probably be limited
anyway, using a fixed percent on large systems might hit some quota,
and even if it doesn't, it'
).
This is maybe not a good idea for people who runs emacs on a big server
with a lot a memory and a lot of users (my emacs is running on a server
with 8Gb of RAM -- 66 users are currently using it --, but wasting 80Mo
between each GC doesn't seem very smar
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.
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
e dependent on the amount of installed
> memory.
Hi Eli,
isn't that the purpose of
gc-cons-percentage
?
--
Adrian Aichner
mailto:[EMAIL PROTECTED]
http://www.xemacs.org/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.
> 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.
>
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, b
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
>> 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 4
ne possible situation where this could happen is if you customize
> > gc-cons-threshold to a large number.
>
> Do you actually mean gc-cons-threshold customized to a *small* number?
No, I meant what I wrote.
> It helps to increase the value of gc-cons-threshold at least tenfolds
>> I noticed too that in sufficiently long Emacs sessions Lisp
>> evaluation slows down.
>
> One possible situation where this could happen is if you customize
> gc-cons-threshold to a large number.
Do you actually mean gc-cons-threshold customized to a *small* number?
(or
> My test case constructed ten thousand times a list of size 1000,
> triggering a lot of garbage collections. In a freshly started Emacs,
> the ring-elements function I propose to install ran the test in 11
> seconds, slightly over 5 being spent in gc. This gives between 5 and
37 matches
Mail list logo
