Re: sorting in C

[Andrew Cohen]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

[...]

    >> I plan to continue playing with changes to the vector algorithm
    >> to see what other changes might be worthwhile.

    EZ> Thank you for working on this.

    EZ> Could you please work on benchmarks for this functionality, and
    EZ> post those benchmarks (and their code if relevant) together with
    EZ> the code changes?  AFAICT, our test suite only includes tests
    EZ> for very small lists and vectors, which is not enough for
    EZ> considering these changes.

Yes. I have been doing only rudimentary benchmarks so far, but will work
on something more substantial.

    >> - if (length < 2) + if (length < 2) { return list; + } else if
    >> (length < 64) { + /* use an iterative insertion sort for short
    >> lists */ + Lisp_Object old = Qnil, new = list, before, after; +
    >> while (CONSP (new)) { + Lisp_Object next = Fcdr (new); + if (NILP
    >> (old) || inorder (predicate, Fcar (old), Fcar (new))) { + old =
    >> new; + new = next; + continue; + }

    EZ> Stylistic comment: the above is not our style of using braces.
    EZ> Please look around in the existing code to see what style we
    EZ> use, and if you have questions, ask them here.

Sure. 

    >> + before = Qnil, after = list;

    EZ> Another stylistic nit: please don't use "foo, bar" where not
    EZ> necessary.  (It basically is only necessary inside parenthesized
    EZ> expressions.)

Sure.

    >> + XSETCDR(new, list); list = new; break;}
    EZ>                    ^^ Please leave one space between the name of
    EZ> a function/macro and the following open parenthesis.

    >> + XSETCDR(before, new); + XSETCDR(new, after);

    EZ> Likewise.

Sure.

    >> + Lisp_Object result = make_nil_vector (length), tail = list;

    EZ> Why not make_uninit_vector?  It's marginally faster, and I don't
    EZ> think you really need to initialize the members to nil, do you?

Yes.  (I only looked at  the C code for the first time a few days ago :))

    >> + int i; + /* convert list to vector */ + for (i=0; i < length;
    >> i++) {

    EZ> "i = 0", with spaces.

Yes.

>> + /* convert vector to list */

    EZ> Text in comments should be complete sentences, and end in 2
    EZ> spaces:

    EZ>    /* Convert vector back to list.  */

All these comments will disappear (or be improved :))

    >> + i = 0; + tail = list; + while (CONSP (tail)) { + XSETCAR (tail,
    >> AREF (result, i)); + tail = XCDR (tail); + i++; + } + return
    >> list; + }

    EZ> Btw, did you also compare the number of GC cycles in the two
    EZ> implementations?  If not, I suggest to include that, since
    EZ> excess GC also slows down real-life Lisp programs.

Again, only rudimentary, so not yet adequate. In playing with lists with
1 million elements I see about the same amount of GC as with the
existing algorithm. But I'm doing this in a not very effective way (I
run each sort many times with benchmark and see what fraction GCs;
mostly it doesn't).

I may need some assistance for this part. I'll put together something
and post it to get started.

    EZ> Last, but not least: it seems like your copyright assignment was
    EZ> only about changes to Gnus?  If so, would you like to start your
    EZ> assignment paperwork at this time, so that by the time you have
    EZ> the code ready, we could accept it without limitations?  If you
    EZ> agree, I will send you the form to fill and the instructions to
    EZ> go with it.

Sure, please do, and thanks in advance. Probably wise since I have made
some small changes in other parts already. 

Best,
Andy

-- 
Andrew Cohen