From: Oleh Krehel <ohwoeowho@gmail.com>
To: Nicolas Richard <theonewiththeevillook@yahoo.fr>
Cc: Nicolas Petton <nicolas@petton.fr>,
Stefan Monnier <monnier@iro.umontreal.ca>,
emacs-devel <emacs-devel@gnu.org>
Subject: Re: Would seq-range and seq-mapcat be useful?
Date: Fri, 30 Jan 2015 17:51:33 +0100 [thread overview]
Message-ID: <CAA01p3o85QibnGzuUeS0kJZruE4P32qxYcYHkFhtror2HVPZ3w@mail.gmail.com> (raw)
In-Reply-To: <54CBB31B.8040309@yahoo.fr>
On Fri, Jan 30, 2015 at 5:36 PM, Nicolas Richard
<theonewiththeevillook@yahoo.fr> wrote:
> Le 30/01/2015 17:04, Oleh Krehel a écrit :
>> Mine's faster:
>
> I think it will depend on the number of keys.
>
> (defmacro util-timeit (&rest expr)
> `(progn
> (garbage-collect) ;; avoid gc later. maybe.
> (let ((t-beg (float-time))
> (res (dotimes (i 500) ;; I reduced this a bit because I have a slow system.
> ,@expr))
> (t-end (float-time)))
> (/
> (- t-end t-beg)
> 500))))
>
> (progn ;; use M-x compile-defun to eval this part
> (defun yf/seq-group-by (fn lst)
> (let ((hash (make-hash-table :test 'equal)))
> (dolist (elm lst)
> (push elm (gethash (funcall fn elm) hash)))
> hash))
> (defun seq-group-by (fn lst)
> (nreverse
> (cl-reduce
> (lambda (acc it)
> (let* ((key (funcall fn it))
> (cell (assoc key acc)))
> (if cell
> (setcdr cell (push it (cdr cell)))
> (push (list key it) acc))
> acc))
> lst
> :initial-value nil))))
>
> (defun make-random-list (n)
> (let ((tmp))
> (dotimes (_ n)
> (push (cons (random 150) t) tmp)) ;; I guess only the keys matter
> tmp))
>
> (let ((tmp (make-random-list 10)))
> (list
> (util-timeit (yf/seq-group-by #'car tmp))
> (util-timeit (seq-group-by #'car tmp))))
> (3.778600692749023e-05 3.6581039428710935e-05)
>
>
> (let ((tmp (make-random-list 100)))
> (list
> (util-timeit (yf/seq-group-by #'car tmp))
> (util-timeit (seq-group-by #'car tmp))))
> (0.0002734408378601074 0.0005863599777221679)
>
>
> (let ((tmp (make-random-list 1000)))
> (list
> (util-timeit (yf/seq-group-by #'car tmp))
> (util-timeit (seq-group-by #'car tmp))))
> (0.00434891939163208 0.010494112968444824)
>
> I wasn't really trying to compete though, just giving another point of
> view.
You're right, of course, I was too fast to judge:).
Exactly this is why we need such a function in the ELPA / core: it
could be complex
enough to do either the alist or the hash-table approach in an optimal
way, since
the homebrew stuff is bound to be simple and work good only in some cases.
Oleh
next prev parent reply other threads:[~2015-01-30 16:51 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-29 16:54 Would seq-range and seq-mapcat be useful? Nicolas Petton
2015-01-29 18:02 ` Artur Malabarba
2015-01-29 22:03 ` Nicolas Petton
2015-01-29 21:40 ` Stefan Monnier
2015-01-29 22:06 ` Nicolas Petton
2015-01-30 6:09 ` Stefan Monnier
2015-01-30 8:00 ` Oleh Krehel
2015-01-30 10:21 ` Nicolas Petton
2015-01-30 15:38 ` Oleh Krehel
2015-01-30 15:59 ` Nicolas Richard
2015-01-30 16:04 ` Oleh Krehel
2015-01-30 16:05 ` Oleh Krehel
2015-01-30 16:36 ` Nicolas Richard
2015-01-30 16:51 ` Oleh Krehel [this message]
2015-01-30 16:23 ` Nicolas Petton
2015-02-02 0:11 ` Nicolas Petton
2015-02-02 7:49 ` Oleh Krehel
2015-02-02 9:28 ` Nicolas Petton
2015-02-02 18:34 ` Mark Oteiza
2015-02-02 18:39 ` Oleh Krehel
2015-02-04 12:02 ` Ted Zlatanov
2015-01-30 8:20 ` What about seq-slice? (Was: Would seq-range and seq-mapcat be useful?) Mark Oteiza
2015-01-30 10:25 ` Nicolas Petton
2015-01-30 11:09 ` seq-thread-first/last (was: What about seq-slice?) Michael Heerdegen
2015-01-30 11:59 ` Nicolas Petton
2015-01-30 12:08 ` seq-thread-first/last Michael Heerdegen
2015-01-30 12:21 ` seq-thread-first/last Nicolas Petton
2015-01-30 12:17 ` seq-thread-first/last David Kastrup
2015-01-30 12:25 ` seq-thread-first/last Nicolas Petton
2015-01-30 12:33 ` seq-thread-first/last Michael Heerdegen
2015-01-30 12:58 ` seq-thread-first/last Bozhidar Batsov
2015-01-30 14:02 ` seq-thread-first/last Artur Malabarba
2015-01-30 14:15 ` seq-thread-first/last Michael Heerdegen
2015-01-30 17:17 ` What about seq-slice? Mark Oteiza
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA01p3o85QibnGzuUeS0kJZruE4P32qxYcYHkFhtror2HVPZ3w@mail.gmail.com \
--to=ohwoeowho@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=nicolas@petton.fr \
--cc=theonewiththeevillook@yahoo.fr \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).