[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] caar/cadr/cdar/cddr
From: |
Tom Tromey |
Subject: |
Re: [RFC] caar/cadr/cdar/cddr |
Date: |
Thu, 12 Jul 2012 10:47:42 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) |
>>>>> "Dmitry" == Dmitry Antipov <address@hidden> writes:
Dmitry> These are widely used, so why not doing them as C primitives and
Dmitry> corresponding bytecodes? It shouldn't be too hard to tweak
Dmitry> byte-opt.el to optimize (car (cdr X)) -> (cadr X) etc., and so
Dmitry> emit new bytecodes.
Did you try to measure the performance benefit?
Dmitry> +(byte-defop 48 0 byte-caar)
Dmitry> +(byte-defop 49 0 byte-cadr)
Dmitry> +(byte-defop 50 0 byte-cdar)
Dmitry> +(byte-defop 51 0 byte-cddr)
Occasionally I wish we were sharing these definitions with bytecode.c;
or more generally that parts of the Emacs core could be written in some
form of Lisp.
Dmitry> + loop:
Dmitry> + if (CONSP (tem))
Dmitry> + {
Dmitry> + if (!EQ (tem, list))
Dmitry> + return XCAR (tem);
Dmitry> + tem = XCDR (tem);
Dmitry> + goto loop;
Dmitry> + }
Dmitry> + else return NILP (tem) ? Qnil : wrong_type_argument (Qlistp, tem);
All these functions are implemented in what seems, to me, a very weird
way. Why not just write the obvious straight-line code?
Tom
- [RFC] caar/cadr/cdar/cddr, Dmitry Antipov, 2012/07/12
- Re: [RFC] caar/cadr/cdar/cddr,
Tom Tromey <=
- Re: [RFC] caar/cadr/cdar/cddr, Tom Tromey, 2012/07/12
- Re: [RFC] caar/cadr/cdar/cddr, Paul Eggert, 2012/07/12
- Re: [RFC] caar/cadr/cdar/cddr, Dmitry Antipov, 2012/07/12
- Re: [RFC] caar/cadr/cdar/cddr, Samuel Bronson, 2012/07/12
- Re: [RFC] caar/cadr/cdar/cddr, Paul Eggert, 2012/07/12
- Re: [RFC] caar/cadr/cdar/cddr, Stefan Monnier, 2012/07/12
- Re: [RFC] caar/cadr/cdar/cddr, Samuel Bronson, 2012/07/12
- Re: [RFC] caar/cadr/cdar/cddr, Stefan Monnier, 2012/07/13
- Re: [RFC] caar/cadr/cdar/cddr, Alp Aker, 2012/07/12