[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pushing the `gnus-range-*' functions down into the C layer
From: |
joakim |
Subject: |
Re: Pushing the `gnus-range-*' functions down into the C layer |
Date: |
Fri, 10 Sep 2010 15:07:05 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
Lars Magne Ingebrigtsen <address@hidden> writes:
> Stefan Monnier <address@hidden> writes:
>
>> I wouldn't rule it out, but I'm reluctant to move Elisp code to C for
>> the same kinds of reason Andy just gave. Especially for such a thing as
>> range/interval algorithms where the best algorithm depends a fair bit on
>> the particular shape of your data.
>> OTOH, speeding up Elisp is not something I expect to happen soon
>> (although moving to lexical bindings is a step in the right direction).
>
> 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 don't think the C layer should be considered "second class". I mean,
> C isn't as nice as Lisp, but it's not like the C style in Emacs is less
> maintainable than most Emacs-Lisp functions out there. :-)
>
> Anyway, back to the range functions. I think it's slightly generally
> useful. My guess would be that if there was a faster
> sorted-integer-list interface, it would be used by others with similar
> needs. `range-memq' would be much faster than `memq' on a list of
> integers in most use cases.
>
>> Maybe once we have dyn-loading in place, Gnus can provide its own
>> C functions outside of Emacs's own C code.
>
> Would that help much, though? Anyway, that reminds me -- I think the
> module support in XEmacs hurt XEmacs more than it helped. You have to
> program so very defensively because you don't know what packages are
> installed by the user. In Emacs, it's so much more productive
> programming, because you can rely on all its bits being present.
Interesting, I havent actually used Xemacs so I didnt know this.
Would you say that this would still be true with a dependency management
mechanism that downloaded and installed required dependencies
automatically?
When I code Clojure, which has a Maven based dependency resolver, I find
that dependencies just get downloaded automatically and I dont need to
spend more time thinking about those kind of issues. But perhaps I'm
missing understanding of some use-case.
>
>> What algorithm does Gnus use currently? I guess you call `sort' and
>> then scan the list looking for contiguous points? That would make it
>> O(n log n), which isn't too bad, but it also means that the C part of
>> the code is O(n log n) and the Elisp part is O(n), so the speed of Elisp
>> should not be a big issue.
>
> In general, the ranges come from the .newsrc.eld file, and are then
> uncompressed before being worked on. The lists are generally kept
> sorted, so it's not necessary to re-sort them before compressing.
>
> 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.
>
>> 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.
>
>> What algorithms do you use there?
>> These should be O(n), right? What do you know about the usual shape of
>> your data? E.g. what's the expected difference between the smallest and
>> the largest element (if it's not too large, we could store them in
>> bitvectors and then provide bitwise or/and on bitvectors)?
>
> It varies a bit. The "read" range is usually on the form
> `(1 . 24254214)', and this is (of course) never uncompressed. But you'd
> usually have additional ranges for, say, ticked, and these would be
> quite sparse, like `(45 (90 . 96) (200 . 259))' Or something like that.
--
Joakim Verona
- Re: Pushing the `gnus-range-*' functions down into the C layer, (continued)
Re: Pushing the `gnus-range-*' functions down into the C layer, Andy Wingo, 2010/09/10
Re: Pushing the `gnus-range-*' functions down into the C layer, Stefan Monnier, 2010/09/10
Re: Pushing the `gnus-range-*' functions down into the C layer,
joakim <=
Re: Pushing the `gnus-range-*' functions down into the C layer, Lars Magne Ingebrigtsen, 2010/09/10
Re: Pushing the `gnus-range-*' functions down into the C layer, Stefan Monnier, 2010/09/10
Re: Pushing the `gnus-range-*' functions down into the C layer, Ted Zlatanov, 2010/09/10
Re: Pushing the `gnus-range-*' functions down into the C layer, Lars Magne Ingebrigtsen, 2010/09/10
Re: Pushing the `gnus-range-*' functions down into the C layer, Stefan Monnier, 2010/09/11
Re: Pushing the `gnus-range-*' functions down into the C layer, Lars Magne Ingebrigtsen, 2010/09/10
Re: Pushing the `gnus-range-*' functions down into the C layer, Daniel Pittman, 2010/09/10