Performance notes for Plug-in Developers

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Performance notes for Plug-in Developers

Bob Zawalich-3
I have just changed a number of plugins after getting reports that they were
running very slowly on large scores. It turns out that some things which are
easy to fix can make a huge speed difference. In particularly, I found that
updating the progress bar too often had a significant speed effect.

So here are a few performance notes.

bob


Performance notes for Plug-in Developers

Plug-ins can run very slowly on large scores with hundreds of thousands of
notes. It is worthwhile to test plug-ins with large orchestral or film
scores to see if the plug-in will be useable with such scores. In addition
to normal efficient programming practices, there are a few simple things you
can do that can make a huge speed difference without having to significantly
change your code.

. Always use score.Redraw = False before making any changes to the
score. Otherwise every change causes the screen to refresh and this is
massively slow. I always reset it to True at the end of a plug-in, but it
might not be necessary to do that.
. If you are updating a progress bar on every bar or every note, it
will greatly slow down processing on a large score. I have found that
updating every 100 objects makes a huge difference and still shows progress.
I use the variable progress for a counter and use "if ((progress % 100 ) =
0)" for a test.
. Writing single lines of text to a text file is very slow compared to
writing a large amount at once. The Dolet plug-in runtime was cut by more
than half by combining a number of lines of text before writing them out.
The straightforward routine WriteOutPlugin in the downloadable Copy Plugin
plug-in writes out 32K byte blocks. Feel free to copy or adapt that code.
. If your plug-ins use the Preferences database be aware that
Preferences.Close will rewrite the text file and this can add several
seconds of delay to a plug-in if the database file is large.  Having a user
strip out some preferences settings running the Preferences plug-in as
described here can save them some runtime. (The shipping plug-in Preferences
could possibly be rewritten to buffer the text writes, which could help).
. Use Dictionaries where you can, both as a replacement for hashes
(faster and can be global), and to quickly sort or search an array, plus
they can hold objects, not just strings. Dictionaries are the best thing to
happen to ManuScript for a long time.
. If you need to change accidentals and are running in Sib 8.3 or
later, use the writeable note.DiatonicPitch rather than adding and deleting
a note.


_______________________________________________
Plugin-dev mailing list
[hidden email]
http://lists.avid.com/mailman/listinfo/plugin-dev_lists.avid.com
Reply | Threaded
Open this post in threaded view
|

Re: Performance notes for Plug-in Developers

Neil Sands
>  I always reset it to True at the end of a plug-in, but it might not be necessary to do that.

I came to the conclusion at some point that it is necessary to reset
Score.Redraw to true, because of some sluggish behaviour in Sibelius
if I didn't. I think dragging the score about with the mouse became
quite frustrating. I can't remember the details really but there was
certainly an issue.

It might have been fixed in the meantime.

On 2 October 2017 at 21:04, Bob Zawalich <[hidden email]> wrote:

> I have just changed a number of plugins after getting reports that they were
> running very slowly on large scores. It turns out that some things which are
> easy to fix can make a huge speed difference. In particularly, I found that
> updating the progress bar too often had a significant speed effect.
>
> So here are a few performance notes.
>
> bob
>
>
> Performance notes for Plug-in Developers
>
> Plug-ins can run very slowly on large scores with hundreds of thousands of
> notes. It is worthwhile to test plug-ins with large orchestral or film
> scores to see if the plug-in will be useable with such scores. In addition
> to normal efficient programming practices, there are a few simple things you
> can do that can make a huge speed difference without having to significantly
> change your code.
>
> .       Always use score.Redraw = False before making any changes to the
> score. Otherwise every change causes the screen to refresh and this is
> massively slow. I always reset it to True at the end of a plug-in, but it
> might not be necessary to do that.
> .       If you are updating a progress bar on every bar or every note, it
> will greatly slow down processing on a large score. I have found that
> updating every 100 objects makes a huge difference and still shows progress.
> I use the variable progress for a counter and use "if ((progress % 100 ) =
> 0)" for a test.
> .       Writing single lines of text to a text file is very slow compared to
> writing a large amount at once. The Dolet plug-in runtime was cut by more
> than half by combining a number of lines of text before writing them out.
> The straightforward routine WriteOutPlugin in the downloadable Copy Plugin
> plug-in writes out 32K byte blocks. Feel free to copy or adapt that code.
> .       If your plug-ins use the Preferences database be aware that
> Preferences.Close will rewrite the text file and this can add several
> seconds of delay to a plug-in if the database file is large.  Having a user
> strip out some preferences settings running the Preferences plug-in as
> described here can save them some runtime. (The shipping plug-in Preferences
> could possibly be rewritten to buffer the text writes, which could help).
> .       Use Dictionaries where you can, both as a replacement for hashes
> (faster and can be global), and to quickly sort or search an array, plus
> they can hold objects, not just strings. Dictionaries are the best thing to
> happen to ManuScript for a long time.
> .       If you need to change accidentals and are running in Sib 8.3 or
> later, use the writeable note.DiatonicPitch rather than adding and deleting
> a note.
>
>
> _______________________________________________
> Plugin-dev mailing list
> [hidden email]
> http://lists.avid.com/mailman/listinfo/plugin-dev_lists.avid.com

_______________________________________________
Plugin-dev mailing list
[hidden email]
http://lists.avid.com/mailman/listinfo/plugin-dev_lists.avid.com
Reply | Threaded
Open this post in threaded view
|

Re: Performance notes for Plug-in Developers

Bob Zawalich-3
It is hard to know when certain procedures are necessary, and if or when
they were fixed, and it pretty unlikely that anyone at Avid/Sibelius could
tell us if it is OK to skip it.

I know that I have had plugins where I did not reset it and things at least
redrew correctly after the plugin ended. But it is a small amount of code to
add the line at the exit points, so I try to do it just in case.

-----Original Message-----
From: Plugin-dev [mailto:[hidden email]] On Behalf Of
Neil Sands
Sent: Monday, October 2, 2017 1:14 PM
To: A mailing list for Sibelius plug-in developers
<[hidden email]>
Subject: Re: [Plugin-dev] Performance notes for Plug-in Developers

>  I always reset it to True at the end of a plug-in, but it might not be
necessary to do that.

I came to the conclusion at some point that it is necessary to reset
Score.Redraw to true, because of some sluggish behaviour in Sibelius if I
didn't. I think dragging the score about with the mouse became quite
frustrating. I can't remember the details really but there was certainly an
issue.

It might have been fixed in the meantime.

On 2 October 2017 at 21:04, Bob Zawalich <[hidden email]> wrote:
> I have just changed a number of plugins after getting reports that
> they were running very slowly on large scores. It turns out that some
> things which are easy to fix can make a huge speed difference. In
> particularly, I found that updating the progress bar too often had a
significant speed effect.

>
> So here are a few performance notes.
>
> bob
>
>
> Performance notes for Plug-in Developers
>
> Plug-ins can run very slowly on large scores with hundreds of
> thousands of notes. It is worthwhile to test plug-ins with large
> orchestral or film scores to see if the plug-in will be useable with
> such scores. In addition to normal efficient programming practices,
> there are a few simple things you can do that can make a huge speed
> difference without having to significantly change your code.
>
> .       Always use score.Redraw = False before making any changes to the
> score. Otherwise every change causes the screen to refresh and this is
> massively slow. I always reset it to True at the end of a plug-in, but
> it might not be necessary to do that.
> .       If you are updating a progress bar on every bar or every note, it
> will greatly slow down processing on a large score. I have found that
> updating every 100 objects makes a huge difference and still shows
progress.
> I use the variable progress for a counter and use "if ((progress % 100
> ) = 0)" for a test.
> .       Writing single lines of text to a text file is very slow compared
to
> writing a large amount at once. The Dolet plug-in runtime was cut by
> more than half by combining a number of lines of text before writing them
out.
> The straightforward routine WriteOutPlugin in the downloadable Copy
> Plugin plug-in writes out 32K byte blocks. Feel free to copy or adapt that
code.
> .       If your plug-ins use the Preferences database be aware that
> Preferences.Close will rewrite the text file and this can add several
> seconds of delay to a plug-in if the database file is large.  Having a
> user strip out some preferences settings running the Preferences
> plug-in as described here can save them some runtime. (The shipping
> plug-in Preferences could possibly be rewritten to buffer the text writes,
which could help).

> .       Use Dictionaries where you can, both as a replacement for hashes
> (faster and can be global), and to quickly sort or search an array,
> plus they can hold objects, not just strings. Dictionaries are the
> best thing to happen to ManuScript for a long time.
> .       If you need to change accidentals and are running in Sib 8.3 or
> later, use the writeable note.DiatonicPitch rather than adding and
> deleting a note.
>
>
> _______________________________________________
> Plugin-dev mailing list
> [hidden email]
> http://lists.avid.com/mailman/listinfo/plugin-dev_lists.avid.com

_______________________________________________
Plugin-dev mailing list
[hidden email]
http://lists.avid.com/mailman/listinfo/plugin-dev_lists.avid.com


_______________________________________________
Plugin-dev mailing list
[hidden email]
http://lists.avid.com/mailman/listinfo/plugin-dev_lists.avid.com