From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: [PATCH] Avoid `SCM_VALIDATE_LIST ()'
Date: Mon, 08 Sep 2008 11:40:37 +0200 [thread overview]
Message-ID: <87y723vuui.fsf@gnu.org> (raw)
In-Reply-To: 49dd78620809061515h72a6d10ev26dc610198b5abbb@mail.gmail.com
Hello!
"Neil Jerram" <neiljerram@googlemail.com> writes:
> I'm sorry but I'm still really struggling to see how this change helps us...
Yes, I see... ;-)
I'm taking it the other way: I can't see how one can argue for unneeded
run-time overhead.
> 2008/9/1 Ludovic Courtès <ludo@gnu.org>:
>> You're right, but it's always better to traverse the list once rather
>> than twice. :-)
>
> Not necessarily. It depends what happens inside the loop, on each
> iteration, and whether the iteration time is significant in comparison
> with that.
I'd say it's better regardless of what's inside the loop.
Sure, one may argue that `memq' is rarely used with million-of-element
lists anyway, because other methods would be used in such situations
(hash tables, etc.). But that's not necessarily the case with
`reverse', `partition', etc.
> What overhead? (Quantifiably, I mean.)
In terms of profile dumps, a full run of the test suite under Callgrind
reveals that `scm_ilength ()' is *not* in the top 10. But hey, one
could surely come up with a Real World(TM) application that does a lot
of list processing and is measurably impacted by that double traversal.
> I don't believe anyone's worked this all out yet, but, for example, if
> the arg to scm_reverse() was generated by some other function that is
> known only to produce proper lists, then the arg might be represented
> as (<proper-list> . the-actual-list), and obviously then the
> SCM_VALIDATE_LIST in scm_reverse() can be completely skipped. If the
> validation code is interleaved with the actually-doing-something code,
> it becomes more difficult to skip (in some hypothetical future).
How would you remove those checks from compiled code like `list.o'?
Guile-VM, OTOH, may have clear opportunities to optimize away certain
cases at compilation time.
> Do we really need to continue this discussion?
Maybe not.
To be honest, I didn't expect I'd have to argue about this in the first
place. I see it as a (maybe small, application-dependent) benefit,
while I have the impression that you regard it solely as a "possible
breakage" and as "code churning". Probably we disagree because we don't
value the same things here.
Thanks,
Ludo'.
next prev parent reply other threads:[~2008-09-08 9:40 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-31 22:02 [PATCH] Avoid `SCM_VALIDATE_LIST ()' Ludovic Courtès
2008-09-01 0:12 ` Han-Wen Nienhuys
2008-09-01 20:19 ` Neil Jerram
2008-09-01 20:30 ` Ludovic Courtès
2008-09-02 2:40 ` Han-Wen Nienhuys
2008-09-06 22:23 ` Neil Jerram
2008-09-06 21:36 ` Neil Jerram
2008-09-07 4:23 ` Ken Raeburn
2008-09-07 15:24 ` Neil Jerram
2008-09-07 17:30 ` Ken Raeburn
2008-09-07 19:21 ` Neil Jerram
2008-09-08 23:11 ` Neil Jerram
2008-09-09 8:28 ` Ludovic Courtès
2008-09-10 20:43 ` Neil Jerram
2008-09-04 18:24 ` Andy Wingo
2008-09-05 0:10 ` Han-Wen Nienhuys
2008-09-05 1:06 ` Andy Wingo
2008-09-06 22:45 ` Neil Jerram
2008-09-07 2:33 ` Han-Wen Nienhuys
2008-09-07 13:38 ` Neil Jerram
2008-09-07 15:00 ` Han-Wen Nienhuys
2008-09-07 16:19 ` Neil Jerram
2008-09-07 19:25 ` Han-Wen Nienhuys
2008-09-07 14:05 ` Andy Wingo
2008-09-07 15:38 ` development goals (was: [PATCH] Avoid `SCM_VALIDATE_LIST ()') Han-Wen Nienhuys
2008-09-07 20:03 ` Neil Jerram
2008-09-08 4:28 ` development goals Han-Wen Nienhuys
2008-09-08 10:16 ` Ludovic Courtès
2008-09-08 13:57 ` Han-Wen Nienhuys
2008-09-09 7:08 ` Andy Wingo
2008-09-08 10:27 ` Ludovic Courtès
2008-09-06 22:40 ` [PATCH] Avoid `SCM_VALIDATE_LIST ()' Neil Jerram
2008-09-01 21:09 ` Neil Jerram
2008-09-01 21:47 ` Ludovic Courtès
2008-09-06 22:15 ` Neil Jerram
2008-09-08 9:40 ` Ludovic Courtès [this message]
2008-09-06 23:11 ` Mikael Djurfeldt
2008-09-07 2:43 ` Han-Wen Nienhuys
2008-09-07 15:04 ` Neil Jerram
2008-09-07 13:32 ` Neil Jerram
2008-09-02 2:44 ` Han-Wen Nienhuys
2008-09-06 22:32 ` Neil Jerram
2008-09-08 3:13 ` Han-Wen Nienhuys
2008-09-08 4:42 ` Clinton Ebadi
2008-09-08 9:47 ` Ludovic Courtès
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/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y723vuui.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-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.
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).