[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why vectors?
- To: srfi-99@xxxxxxxxxxxxxxxxx
- Subject: Re: Why vectors?
- From: Derick Eddington <derick.eddington@xxxxxxxxx>
- Date: Mon, 11 Aug 2008 14:50:22 -0700
- Delivered-to: srfi-99@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=ZM6EWhlcq/QOpgncQk+XwoBWcPZShEDFiklJ+0zwJQI=; b=l2qYHWclIXswYq3ZkN3sKKvO5APbbTtx+mBsz2XfaWSETvX/SuQifnbNyBQx3nwPVm ORDuBRmDcGoCbJPc4gxfqEW7BqRGfMTC1GoxcPAvcD6oedD/zkoOAtRjvcOUNp8Sx+3Z +gxHJbPq3CwWZ3RNE5GvxZ2FuvJxQGCqmarKQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=L/0SWZx73gW22C6903i6eZ/w/lLE2rIJsR3dNCekjp5vG6Crgqf0xSufXhHklr5516 AAJseYiUWa8J4ckODxhcTTkNKmB5j01s/7sRVywFr7HUzQDmA0R1zpmPIrbz/r8lJF9g 7asGiHCxCXKz7zVezUOaFbZLuIqim6wXliPwQ=
- In-reply-to: <489FEA3F.7050706@xxxxxxxxxxx>
- References: <1218433189.7249.107.camel@eep> <489FEA3F.7050706@xxxxxxxxxxx>
On Mon, 2008-08-11 at 09:29 +0200, Per Bothner wrote:
> Derick Eddington wrote:
> > Why are vectors and not lists used for make-rtd's and rtd-constructor's
> > fieldspecs arguments and for rtd-field-names's and rtd-all-field-names's
> > return values? Is the only reason to follow R6RS's use of vectors? If
> > so, I request lists be used instead because they're easier to deal with,
> > as shown by how much list<->vector conversion is done in the ERR5RS
> > reference implementation itself. Using lists instead would increase the
> > appeal of this SRFI to me, and I think to others also. IMO,
> > interoperating with the R6RS records procedures that deal in vectors
> > without having to convert list<->vector is not a good enough reason
> > compared to the benefit of using lists with one's primary record system
> > of use, because interoperating at the procedural level where these
> > vectors matter will be rare (I imagine). Or is there a good reason to
> > use vectors?
> Well, of course performance-wise vectors are much more efficient than
> lists as a general rule, but it mostly matters for either freequently-
> accessed or long-term-retention sequences. Clearly, the internal data
> structures used to represent classes should be vectors. In that case,
> it can be more efficient to have reflective operations also return
> (immutable) vectors - at least if return sequences can be the same
> as the internal sequences.
I've been assuming the internal data structures of records would not
need to be less efficient in order to use lists for make-rtd's and
rtd-constructor's fieldspecs arguments and for rtd-field-names' and
rtd-all-field-names' return values.
Having lists be used instead isn't a big deal to me, and I'm being the
Devil's advocate about this because I want to make sure there's really a
compelling reason to use vectors for the API's field specifiers instead
of the more natural and convenient (to me, at least) lists.
make-rtd and rtd-constructor will be used infrequently enough (right?)
that there's not really a performance concern over having to convert a
list fieldspecs argument into whatever is needed, is there? The current
draft's make-rtd fieldspecs argument already requires processing because
of its syntax, right?
If rtd-field-names can directly return an internal data structure,
that's obviously going to be the most efficient, but will it be able to
or should it do that? Is it really a performance concern?
Implementations of rtd-all-field-names will probably use
rtd-field-names, so rtd-all-field-names' performance will be affected by
rtd-field-names, but is it really a concern?
What is an example where the efficiency of using vector field specifiers
versus list field specifiers for the API matters?
rtd-accessor and rtd-mutator take a field name symbol argument (I like
that) instead of a numeric index like R6RS does, and that seems like a
similar performance concern which might not really need to be a concern.
What could a sophisticated optimizing compiler do for these six