Re: Pushing the `gnus-range-*' functions down into the C layer

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Actually, I think Emacs could do with moving more things down into the C
> layer.  I mean, having en elisp implementation of sha1 is quite an
> achievement, but linking with libgcrypt would have given you that and
> much more.  Just to take a random example.

I won't try to argue that sha1 in Elisp is a good idea, indeed.
There's no hard rule here, it's just a general preference for Elisp code.

> I don't think the C layer should be considered "second class".

It can't be modified from the .emacs, so it is necessarily second class.
But of course for functions like sha1 where speed matters and where the
functionality and API is stable, C is a better choice.

> Anyway, back to the range functions.  I think it's slightly generally
> useful.

I wouldn't dream of arguing that intervals are not generally useful.
Hell, we use them for text-properties.  But I think that if we want to
provide something like that from C, we should try and make them better
than just "sorted lists of cons cells".  If the code can be shared with
the one for text-properties (which uses a balanced binary tree), that's
even better.

> But I think you kinda underestimate how slow Emacs Lisp is compared to
> C.  An O(n) function in Emacs Lisp can be slow enough to make it
> unpleasant for the user.

I know how slow Elisp is, yes.  AFAIC it's the only reason why I'd ever
consider moving to another language.

>> Ah, so you don't just convert to/from lists of points to intervals, but
>> you also work directly on intervals.
> At present, they're compressed and uncompressed, because memq is much
> faster in the general use cases than the Lisp range-member functions.
> But if range-memq was present in C, then I'd never uncompress.

Hmm... so how 'bout installing a C version of range-memq and keep
everything else in Elisp?  Would that be good enough as a "quick fix"?


        Stefan