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
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
> 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
>> 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 not customized at all si
> 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
> 6 for the functio
I guess that in a really big Emacs, gc will take even much longer. It
is not very surprising that the more objects gc has to check, the
longer it takes. I believe this pretty much explains the gradual
slowdown of Emacs as it grows older (and hence bigger).
Thanks for demonstratin
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
6 for the function itself.
Eli Zaretskii wrote:
One possible situation where this could happen is if you customize
gc-cons-threshold to a large number.
I have:
gc-cons-threshold: Hide Value 40
State: STANDARD.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-d
> From: Juri Linkov <[EMAIL PROTECTED]>
> Date: Wed, 22 Jun 2005 19:28:55 +0300
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> > Apparently these timings are not very fixed. In a freshly started
> > Emacs, my proposed version took 12 seconds (instead of earlier 23) and
> > the abstract versions
> Apparently these timings are not very fixed. In a freshly started
> Emacs, my proposed version took 12 seconds (instead of earlier 23) and
> the abstract versions 40 seconds (instead of 51). This gives a
> mysterious gain of 11 seconds for both. But now my proposed version
> runs 3.33 times fa
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Apparently these timings are not very fixed. In a freshly started
> Emacs, my proposed version took 12 seconds (instead of earlier 23) and
> the abstract versions 40 seconds (instead of 51). This gives a
> mysterious gain of 11 seconds for both. But n
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> ring-ref does not rotate the ring, nor does it "exhaust" it. Maybe
> you mean `ring-remove', but that would force me to copy the ring first.
you're right. i was thinking destructively (been reading Il Signore
Degli Annelli, that's my excuse :-)... so
Apparently these timings are not very fixed. In a freshly started
Emacs, my proposed version took 12 seconds (instead of earlier 23) and
the abstract versions 40 seconds (instead of 51). This gives a
mysterious gain of 11 seconds for both. But now my proposed version
runs 3.33 times faster than
After thinking a bit more, the algorithm I propose to install (took 23
seconds in the test case) seems clearly superior over the one that
took 20 seconds. The reason is that my proposed algorithm is linear
in the _length_ of the ring, the 20 second algorithm is linear in the
_size_ of the ring. T
Thien-Thi Nguyen wrote:
an index of -1 returns the "oldest" element.
so you could just `(ring-ref ring -1)' until the
ring is exhausted, obviating both `nreverse' and
`var' reference, while keeping the abstraction.
ring-ref does not rotate the ring, nor does it "exhaust" it. Maybe
yo
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> (defun ring-elements (ring)
> "Return a list of the elements of RING in order, newest first."
> (let (lst)
> (dotimes (var (ring-length ring))
> (push (ring-ref ring var) lst))
> (nreverse lst)))
an index of -1 returns the "oldest" ele
was quadratic. It essentially does ring-length times an aref in
_vector_, which unlike checking the element at an average position in
a _list_, would not appear to be linear in the size of the vector.
If it is a vector, you're right, it isn't quadratic.
_
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Richard Stallman wrote:
>
>If you want to do a little work, I am sure you could write a single
>loop that produces the right elements in the right order. Then you
>could rotate it properly with a single call to setcdr followed by
>nconc'
Richard Stallman wrote:
If you want to do a little work, I am sure you could write a single
loop that produces the right elements in the right order. Then you
could rotate it properly with a single call to setcdr followed by
nconc'ing the pieces in the opposite order.
Unless I am com
No. The bug is that if the size of the ring is larger than the
length, the current version of `ring-elements' introduces fake `nil'
elements. The delq gets rid of all nil's, fake ones and potentially
legitimate ones, because certain ring elements could _really_ be nil.
The nco
Richard Stallman wrote:
(defun ring-elements (ring)
"Return a list of the elements of RING in order, newest first."
(let (lst)
(dotimes (var (ring-length ring))
(push (ring-ref ring var) lst))
(nreverse lst)))
Isn't that quadratically
Maybe I am trying to document a bug here. Maybe it is better not to
add these two sentences and instead make `ring-elements' do what the
first sentence above, and its docstring, say it does.
I think so.
! (nconc lst (make-list (- (ring-length ring) (length lst)) nil
What
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Actually, if we have to do all of that to get the correct return
> value, we could quite as well use the following function, which does
> get the order correct:
>
> (defun ring-elements (ring)
> "Return a list of the elements of RING in order, newest f
Actually, if we have to do all of that to get the correct return
value, we could quite as well use the following function, which does
get the order correct:
(defun ring-elements (ring)
"Return a list of the elements of RING in order, newest first."
(let (lst)
(dotimes (var (ring-length rin
>From my previous message:
@defun ring-elements ring
This returns a list of the objects in @var{ring}, in no particular
! order. The length of that list is always the ring size. If the ring
! length is less than the ring size, the entries of the list that do not
! correspond t
The following patch to ring.el is equivalent to the one I sent
earlier, but probably slightly better:
===File ~/ring.el-diff-b
*** ring.el 02 Sep 2003 07:41:57 -0500 1.18
--- ring.el 18 Jun 2005 18:53:24 -0500
***
*** 155,162
I recommend the following changes to lists.texi and can install if
desired. In as far as spelling issues are concerned, `vs' seems to be
the standard abbreviation of `versus' and `indices' seems to be the plural
form of `index' consistently used in the Elisp manual.
In as far
32 matches
Mail list logo
