headers
Liam Healy | 5 May 2012 17:40
Picon

Round trips through parse-type, unparse-type

I just pushed fixes to make the FSBV tests pass.  One fix was to the recursive call to libffi-type-pointer that took the slot-type directly, already unparsed, and tried to unparse it.   I fixed that by parsing it again.  In the course of debugging this, I found this comment in defclass foreign-struct-slot
 ;; FIXME: the type should probably be parsed?
I briefly investigated doing this, and decided to take the expedient route for now.

However, this comment got me to thinking that there are a lot of (unnecessary) round trips through parse-type/unparse-type.  It seems to me that they could be eliminated or reduced.  Perhaps as a design philosophy, we should only have parsed types internally, and then we won't need unparse-type at all?   Changing this would be a lot of work, I realize.

Liam

_______________________________________________
cffi-devel mailing list
cffi-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Permalink | Reply |
headers
Luís Oliveira | 6 May 2012 12:13
Picon
Gravatar

Re: Round trips through parse-type, unparse-type

On Sat, May 5, 2012 at 4:40 PM, Liam Healy <lnp <at> healy.washington.dc.us> wrote:
> However, this comment got me to thinking that there are a lot of
> (unnecessary) round trips through parse-type/unparse-type.  It seems to me
> that they could be eliminated or reduced.  Perhaps as a design philosophy,
> we should only have parsed types internally, and then we won't need
> unparse-type at all?   Changing this would be a lot of work, I realize.

What makes you say there are a lot round-trips through parse- and
unparse-type? Grepping the source we code, we can find two usages of
unparse-type: (1) the make-load-form method for foreign-type and (2)
some foreign-array-type code.

(2) shouldn't be there and it's got a FIXME nearby. (1) is why
unparse-type was introduced. Instances of foreign-type can end up in
fasls after various macros and compiler macros kick in and so we need
a way to serialize them.

Cheers,

--

-- 
Luís Oliveira
http://r42.eu/~luis/
Permalink | Reply |
headers
Liam Healy | 11 May 2012 05:38
Picon

Re: Round trips through parse-type, unparse-type

n Sun, May 6, 2012 at 6:13 AM, Luís Oliveira <luismbo <at> gmail.com> wrote:
On Sat, May 5, 2012 at 4:40 PM, Liam Healy <lnp <at> healy.washington.dc.us> wrote:
> However, this comment got me to thinking that there are a lot of
> (unnecessary) round trips through parse-type/unparse-type.  It seems to me
> that they could be eliminated or reduced.  Perhaps as a design philosophy,
> we should only have parsed types internally, and then we won't need
> unparse-type at all?   Changing this would be a lot of work, I realize.

What makes you say there are a lot round-trips through parse- and
unparse-type? Grepping the source we code, we can find two usages of
unparse-type: (1) the make-load-form method for foreign-type and (2)
some foreign-array-type code.

(2) shouldn't be there and it's got a FIXME nearby. (1) is why
unparse-type was introduced. Instances of foreign-type can end up in
fasls after various macros and compiler macros kick in and so we need
a way to serialize them.

Cheers,

--
Luís Oliveira
http://r42.eu/~luis/

Ah, OK, not round trips, forget what I said about unparse-type.  My sense is there's repeated reparsing.  If a type was always parsed when read, and the parsed form is stored, would that save some reparsing?   So the type slot in foreign-struct-slot would not need to be parsed each time it's used.

Thanks,
Liam
_______________________________________________
cffi-devel mailing list
cffi-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Permalink | Reply |
headers
Luís Oliveira | 11 May 2012 09:15
Picon
Gravatar

Re: Round trips through parse-type, unparse-type

On Fri, May 11, 2012 at 4:38 AM, Liam Healy <lnp <at> healy.washington.dc.us> wrote:
> Ah, OK, not round trips, forget what I said about unparse-type.  My sense is
> there's repeated reparsing.  If a type was always parsed when read, and the
> parsed form is stored, would that save some reparsing?   So the type slot in
> foreign-struct-slot would not need to be parsed each time it's used.

Right, I think it would make sense for struct slots to be parsed. I
suspect that they aren't because that code predates the concept of
parsed types in CFFI, hence the FIXME.

In practice this is not a performance issue because the compiler macro
for foreign-struct-slot wil perform parsing at compile-time. Also, the
current scheme lets us pass the unparsed type to mem-ref directly. If
the type were to be parsed, we'd need a version of mem-ref that
accepts a parsed type. Shouldn't be too hard, I suppose.

--

-- 
Luís Oliveira
http://r42.eu/~luis/
Permalink | Reply |

Gmane