Re: [Emacs-diffs] trunk r117007: Optimize cl-struct-slot-value; fix test

Re: [Emacs-diffs] trunk r117007: Optimize cl-struct-slot-value; fix test

[Stefan Monnier]

> -  (elt inst (cl-struct-slot-offset struct-type slot-name)))
> +  ;; We could use `elt', but since the byte compiler will resolve the
> +  ;; branch below at compile time, it's more efficient to use the
> +  ;; type-specific accessor.
> +  (if (eq (cl-struct-sequence-type struct-type) 'vector)
> +      (aref inst (cl-struct-slot-offset struct-type slot-name))
> +    (nth (cl-struct-slot-offset struct-type slot-name) inst)))

It won't always resolve the (eq (cl-struct-sequence-type struct-type)
'vector) test at compile-time, tho.


        Stefan

Re: [Emacs-diffs] trunk r117007: Optimize cl-struct-slot-value; fix test

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On 04/21/2014 09:34 PM, Stefan Monnier wrote:
>> -  (elt inst (cl-struct-slot-offset struct-type slot-name)))
>> +  ;; We could use `elt', but since the byte compiler will resolve the
>> +  ;; branch below at compile time, it's more efficient to use the
>> +  ;; type-specific accessor.
>> +  (if (eq (cl-struct-sequence-type struct-type) 'vector)
>> +      (aref inst (cl-struct-slot-offset struct-type slot-name))
>> +    (nth (cl-struct-slot-offset struct-type slot-name) inst)))
> 
> It won't always resolve the (eq (cl-struct-sequence-type struct-type)
> 'vector) test at compile-time, tho.

It did in my tests, when struct-type was a symbol. When struct-type is
something that might vary, the branch shows up in the bytecode. Maybe
the comment should say "will resolve...when possible".


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [Emacs-diffs] trunk r117007: Optimize cl-struct-slot-value; fix test

[Stefan Monnier]

>> It won't always resolve the (eq (cl-struct-sequence-type struct-type)
>> 'vector) test at compile-time, tho.
> It did in my tests, when struct-type was a symbol.

Yes, it does for the case where we could have used the accessor instead
(tho I understand there are cases where using the accessor is impractical).
But I'm not convinced this should be a common case.

> When struct-type is something that might vary, the branch shows up in
> the bytecode.

Not only the branch but the cl-struct-sequence-type call as well.
Ends up much more expansive than an `elt'.

I used `elt' in my original code because my benchmark made me think that
replacing `elt' with `aref' is not worth the extra cost when we can't do
that (the speed difference just for the elt/aref call is less than 10%,
which gets drowned in the noise when you add the typep test; for the
setter, the impact is a bit higher since we end up adding a listp test
which can't be optimized away (contrary to your test), but there again,
the difference is pretty small in practice).

Anyway, either code is fine.  I just wanted to share the results of
my benchmarketting.


        Stefan