4 Replies Latest reply on Jul 16, 2011 4:41 PM by areohbee

    LrTasks.yield as a plugin execution time benchmark

    jarnoh Level 1



      I've been investigating how much execution time Lightroom actually gives to plugins.  When a develop preset is applied, Lightroom renders a new preview of the image, and during this time plugin is not getting any execution time and of course the plugin cannot abort the preview rendering either.  This is especially annoying I have slider in my plugin that adjust the image on the fly, the users (and I) expect at least some sort of realtime feedback.  Now the UI slider isn't even moving while Lightroom is rendering.


      So, I made a little plugin experiment with LrTasks.yield in a busy loop and logging number of yields executed per second.  On Mac (2.2Ghz dual), the plugin runs about 16000 yields per second when idling (lightroom takes 100% cpu time of one core).  On Windows (2.5Ghz quad), the idle yield count varies a lot more, it is generally 80-160 per second (cpu usage 0%).


      The idle count really just proves that you shouldn't yield too often in Windows. 


      But - things get more interesting when I use my plugin's slider to adjust image.  On Mac, the plugin doesn't really get any time, yield counts drop from 16000 to below 10. On Windows, I still get 30-40 yields per second.  Of course the computers are totally different, but I still cannot understand those yield counts when plugin is busy...



        • 1. Re: LrTasks.yield as a plugin execution time benchmark
          DFBurns Level 1

          I think the only thing you can conclude from what you see is that there are differences in what you should expect from the yield() call across operating systems and that you should not rely on it for any sort of reliable benchmarking. You're getting into the area of reverse-engineering both Lightroom's threading model on each platform and the operating systems' own scheduling algorithms.


          For example, there was another thread on this in this forum a while ago and someone noticed that Yield on Windows didn't return for 10ms (or was it 15?). If you look into available documentation on Windows' scheduler, the size of a quantum is either 10 or 15ms depending on the CPU configuration. Seems correlated, no? Maybe Lr's implementation on Mac isn't as tightly bound to low-level OS scheduling or maybe it is but Mac's scheduler just works differently. It will be complex to derive reliable info here: I see that my running instance of Lr on 64-bit Win7 has 33 threads just while sitting idle. What are they doing? Which are used for exports and plugins or does Lr start new ones for those? I wish you luck but I don't have high hopes for reaching a conclusion. And if you do, it could all be changed in Lr 4.

          • 3. Re: LrTasks.yield as a plugin execution time benchmark
            jarnoh Level 1

            I've now disabled all other plugins, now I'm seeing steady 64 yield rate.  I wonder why it was larger before, perhaps some of the internal plugins?  I'm also getting single 1000 times per second yield peak when I close my plugin's dialog.


            The point isnt really how slow or fast yield is, but if the plugin is getting any runtime at all.  Ideally, I'd like to cancel the rendering when user changes slider value.



            • 4. Re: LrTasks.yield as a plugin execution time benchmark
              areohbee Level 5

              I doubt I'll be able to help much. but here are some things I've noticed:


              Lightroom will not yield much CPU to plugins if its busy with something like rendering.

              But also, plugins will not yield much to Lightroom if they are busy doing something, and not yielding.


              Put another way, plugin will be CPU starved whenever Lightroom is busy, and

              Lightroom will hang if a plugin is in an infinite loop without yielding (or sleeping...).


              Put another-nother way, relationship between plugin and Lightroom is non-pre-emptive (in both directions), and plugin does not have higher priority than any of Lightroom's activities, not sure if it actually is last on the list or what...


              I'm not sure how Adobe has handled making the develop module sliders so fluid despite constant need to restart the rendering - not a clue...


              (I assume you've already noted the yield performance difference between Windows & Mac)


              I don't know how apps like LrPad (remote develop module extension for iPad) have handled this, which has sliders that are supposedly changing dev settings in real time remotely, except that the sliders are in the iPad, not a plugin.


              If I were doing this, I would *not* use a plugin for the UI, but an app that can take a slice of the CPU from Lightroom regardless of whether Lightroom is giving it (i.e. CPU scheduled pre-emptively by OS). Then, use a plugin just for the dev-setting.


              PS - I have used http for app <--> plugin communication, as well as file-system.