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
On Sat, May 5, 2012 at 4:40 PM, Liam Healy lnp@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,
n Sun, May 6, 2012 at 6:13 AM, Luís Oliveira luismbo@gmail.com wrote:
On Sat, May 5, 2012 at 4:40 PM, Liam Healy lnp@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
On Fri, May 11, 2012 at 4:38 AM, Liam Healy lnp@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.
-
Liam Healy -
Luís Oliveira