Am 10.07.2018 um 16:48 schrieb David Kastrup:
Urs Liska <li...@openlilylib.org> writes:
Hi all,
after completing most of the work of reviewing the scholarly.annotate
module I realize that it (presumably one small change) is a total
performance killer, and I need some help tracking it down.
Well, one thing just jumping out at me is
((process-acknowledged translator)
(for-each
(lambda (grob)
[...]
;; reset list to prevent multiple processing.
;
; TODO: I don't understand why I can kill *all* the list
; after having processed *one* grob.
; What happens to any other annotated grobs (at the same
time)?
; I know it is possible to annotate multiple post-events,
for example.
(set! all-grobs '())))))))
all-grobs))
That's just garbage. If you want to stop processing the list in spite
of having started it with for-each, you need a non-local jump
(catch/throw).
The list processed by for-each has no connection at all with what you
store in all-grobs inside of the loop. And it does not appear like you
even bother resetting all-grobs at all when you don't reach the
conditional passage inside, letting it grow at will.
... which is basically what I arrived at with more investigation in my
other post.
I was aware that this "set!" doesn't break the for-each, but I thought I
should do let *this* loop run through to the end because in the
*current* list there might be other grobs I need to process.
What I missed was that the list wasn't emptied when *no* grob matched
the condition. So ironically the list grew longer with less annotations
present.
What seems to fix it (at least with the one test I could do before
leaving) is setting the list to an empty list in start-translation-timestep.
Still I don't feel confident about what exactly happens in what step of
the process ...
Let's see how that latest change plays out.
Thanks
Urs
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
