From: joakim@verona.se
To: emacs-devel@gnu.org
Subject: Re: Pushing the `gnus-range-*' functions down into the C layer
Date: Fri, 10 Sep 2010 15:07:05 +0200 [thread overview]
Message-ID: <m3fwxh3fye.fsf@verona.se> (raw)
In-Reply-To: <m3tylxojxo.fsf@quimbies.gnus.org> (Lars Magne Ingebrigtsen's message of "Fri, 10 Sep 2010 14:35:31 +0200")
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> 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
next prev parent reply other threads:[~2010-09-10 13:07 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-09 15:16 Pushing the `gnus-range-*' functions down into the C layer Lars Magne Ingebrigtsen
2010-09-09 19:01 ` Ted Zlatanov
2010-09-09 21:58 ` Lars Magne Ingebrigtsen
2010-09-09 22:25 ` Ted Zlatanov
2010-09-10 3:24 ` Stephen J. Turnbull
2010-09-10 13:53 ` Ted Zlatanov
2010-09-10 14:01 ` Lars Magne Ingebrigtsen
2010-09-10 14:08 ` Leo
2010-09-10 14:15 ` Lars Magne Ingebrigtsen
2010-09-10 14:19 ` Wojciech Meyer
2010-09-11 9:44 ` Stefan Monnier
2010-09-10 14:18 ` Ted Zlatanov
2010-09-10 14:28 ` Lars Magne Ingebrigtsen
2010-09-10 14:38 ` bignums (was: Pushing the `gnus-range-*' functions down into the C layer) Ted Zlatanov
2010-09-10 15:16 ` Pushing the `gnus-range-*' functions down into the C layer Andreas Schwab
2010-09-10 15:22 ` David Kastrup
2010-09-10 15:26 ` Lars Magne Ingebrigtsen
2010-09-11 9:48 ` Stefan Monnier
2010-09-11 11:57 ` Lars Magne Ingebrigtsen
2010-09-11 15:36 ` Stephen J. Turnbull
2010-09-11 15:51 ` Lars Magne Ingebrigtsen
2010-09-11 16:15 ` Wojciech Meyer
2010-09-12 9:57 ` Stefan Monnier
2010-09-10 19:28 ` Tom Tromey
2010-09-14 15:52 ` Ted Zlatanov
2010-09-11 5:52 ` Stephen J. Turnbull
2010-09-13 11:45 ` Eli Zaretskii
2010-09-09 22:21 ` Wojciech Meyer
2010-09-09 23:48 ` Ted Zlatanov
2010-09-09 23:56 ` Wojciech Meyer
2010-09-10 0:07 ` Lars Magne Ingebrigtsen
2010-09-10 0:17 ` Wojciech Meyer
2010-09-10 8:06 ` Andy Wingo
2010-09-10 10:20 ` Wojciech Meyer
2010-09-10 10:43 ` Stefan Monnier
2010-09-10 12:35 ` Lars Magne Ingebrigtsen
2010-09-10 12:49 ` rfc2047-decode-string in C? Lars Magne Ingebrigtsen
2010-09-10 13:47 ` Stefan Monnier
2010-09-10 13:51 ` Lars Magne Ingebrigtsen
2010-09-11 16:10 ` Lars Magne Ingebrigtsen
2010-09-10 13:07 ` joakim [this message]
2010-09-10 13:22 ` Pushing the `gnus-range-*' functions down into the C layer Lars Magne Ingebrigtsen
2010-09-10 13:45 ` Stefan Monnier
2010-09-10 14:01 ` Ted Zlatanov
2010-09-10 14:09 ` Lars Magne Ingebrigtsen
2010-09-11 9:36 ` Stefan Monnier
2010-09-10 14:06 ` Lars Magne Ingebrigtsen
2010-09-11 3:18 ` Daniel Pittman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3fwxh3fye.fsf@verona.se \
--to=joakim@verona.se \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.