Re: Efficiency of alist vs. vector/array

[Urs Liska]

Am 19.07.2017 um 10:43 schrieb David Kastrup:
> Urs Liska <address@hidden> writes:
>
>> Obviously I didn't make myself clear enough and probably I should have
>> invested the time for a minimal example. When sloppily using the word
>> "override" I didn't mean "\override" but applying a value to a grob
>> property in a grob callback function.
>>
>> I have a data structure idTweaks, currently using an alist:
>>
>>     idTweaks = #'()
>>
>> This alist gets populated with elements consisting of a key and a
>> #'(property . value) pair with
>>
>> idTweak =
>> #(define-void-function (id prop val)(string? symbol? scheme?)
>>    (set! idTweaks (assoc-set! idTweaks id (cons prop val))))
>>
>> using commands like
>>
>> \idTweak "id-1" color #red
>> \idTweak "id-2" extra-offset #'(2 . -2)
> You are aware that
>
> idTweaks.id-1.color = #red
> idTweaks.id-2.extra-offset = #'(2 . -2)
>
> would have done the same?

No!
(but only if id-1 were a symbol, right?

>> In the callback stage the callback function looks up if a grob has an
>> 'id property and if there's a matching entry in idTweaks:
>>
>> #(define (apply-tweaks grob)
>>    (let*
>>     ((id (ly:grob-property grob 'id))
>>      (tweak (if (null? id)
>>                 #f
>>                 (assoc-ref idTweaks id))))
>>     (if tweak
>>         (ly:grob-set-property! grob (car tweak) (cdr tweak)))))
> At any rate: yes it would make sense to use a hashtable here.  

OK, good to know (and be confirmed).

> It would
> also make a lot of sense to use 'id-1 (namely a symbol) rather than
> "id-1" for lookup since symbols are much easier and faster to compare
> for equality than strings are (and can be compared using eq? rather than
> equal?).  

In fact in my real example I *do* change the typecheck of the id
property to use symbols, but I didn't want to complicate the minimal
example :-)

> I wouldn't tamper with the alist-based property handling of
> grobs though.

I didn't think about such a thing.

Best
Urs

-- 
address@hidden
https://openlilylib.org
http://lilypondblog.org