Re: Efficiency of alist vs. vector/array

[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?

> 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.  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?).  I wouldn't tamper with the alist-based property handling of
grobs though.

-- 
David Kastrup