XBMC Community Forum
DialogProgress performance - Printable Version

+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Python Add-on Development (/forumdisplay.php?fid=26)
+--- Thread: DialogProgress performance (/showthread.php?tid=77809)

Pages: 1 2


DialogProgress performance - jingai - 2010-07-24 23:25

I've just patched the iPhoto plugin to use DialogProgress to prevent the script error when you import the iPhoto library.

But, it's extremely slow. I'm passing the progress dialog to a callback to update it. It takes roughly 45 seconds to import my library if I do this versus 3-4 seconds if I don't.

However, if I call the library update function prior to displaying the root directory, it runs in 3-4 seconds like it should, even with the progress dialog.

Anyone have any ideas? Source is at git://github.com/jingai/plugin.image.iphoto.git if you'd like to have a look.

I'm testing on XBMC r32042. I see the same behavior on both MacOS X and Linux, both with and without debugging enabled.

There are no errors in the log, either.

Thanks,
Jonathan


- jmarshall - 2010-07-25 01:04

How often are you updating the progress bar? Updating it too frequently might cause this problem - particularly when XBMC is wanting to update it as well (as it's waiting on the plugin)


- jingai - 2010-07-25 02:26

jmarshall Wrote:How often are you updating the progress bar? Updating it too frequently might cause this problem - particularly when XBMC is wanting to update it as well (as it's waiting on the plugin)

I should have been clearer. The time wasted isn't in the updating of the dialog.

The plugin updates the dialog once per image found. If I run it without the progress dialog, this translates to roughly 1000 times per second (in my case, at least, with 3000 images). But I've tried limiting the updates to n % 10 (300 total dialog updates) and n % 100 (30 total dialog updates) and the elapsed time remains the same -- about 45 seconds.

However, the weird thing is that if I import the library before populating the root directory listing (specifically, before calling plugin.endOfDirectory), it runs in 3-4 seconds like it should, updating the dialog as quickly as I'd expect.

But if I import it after the root directory has been displayed, it takes 45 seconds or so. I've tried making the progress dialog a global rather than passing it by reference to the callback and I get the exact same behavior.

-j


- jingai - 2010-07-25 02:28

jmarshall Wrote:particularly when XBMC is wanting to update it as well (as it's waiting on the plugin)

Just to try to be even clearer -- I see exactly the _opposite_ of this. If XBMC is also updating the progress dialog (like when it's waiting on the directory listing when you first start the plugin), it runs quickly. Very, very odd.

-J


- elupus - 2010-07-25 13:21

The call to update the progress bar is a very very slow call. Ie you can't call it more than 60 times per second. (it matches fps). If displaying the directory causes a fps slowdown, that would mean even less than 60 times per second. 30 or even 20 if vsync is on.

This is clearly far from ideal.

Jmarshall:
Plugins don't even need to call the explicit progressbar update nowadays do they? We will display busy dialog and do the progressdialog update from that thread instead.


- jingai - 2010-07-25 14:35

elupus Wrote:The call to update the progress bar is a very very slow call. Ie you can't call it more than 60 times per second. (it matches fps). If displaying the directory causes a fps slowdown, that would mean even less than 60 times per second. 30 or even 20 if vsync is on.

I realize it's a slow call. I'm trying to say that my import operation is slowed by an order of magnitude even if I don't update the progress dialog _at all_. Just displaying the dialog causes the import to be slow.

Conversely, if I do the import operation before the root directory is populated, it runs nominally, even when updating the dialog 1000 times/second. This is exactly what's odd: fighting XBMC's own progress updates appears to be _faster_.

The problem I'm having isn't with unrealistic expectations of the update() call.

Quote:Plugins don't even need to call the explicit progressbar update nowadays do they? We will display busy dialog and do the progressdialog update from that thread instead.

If XBMC is waiting for a directory listing, this is true. However, it shows no progress dialog for any other busy operation.

-Jonathan


- jingai - 2010-07-25 16:49

Here, I've made a separate plugin that serves only to show what I'm talking about. You can get it here.

This example doesn't do _anything_ except xbmc.sleep(1) in the updater. The third menu item shows you how quick it should be, and the first two items show how slow it is if XBMC isn't waiting on a directory listing.

On my Linux box with XBMC r32042, the [SLOW] items take 50 seconds (with and without dialog updates), and the [FAST] item takes 5 seconds (with updates).

I'm kind of at a loss here.. I've stripped out literally everything Sad

-Jonathan


- Nuka1195 - 2010-07-25 17:24

i've mentioned something similar before.

it would also be nice to be able to disable the auto progress bar for plugins that require a long setup on first run.


- jingai - 2010-07-25 17:30

Nuka1195 Wrote:i've mentioned something similar before.

So in your opinion, it's a bug? As opposed to me doing something wrong?

Quote:it would also be nice to be able to disable the auto progress bar for plugins that require a long setup on first run.

Aye, that would be nice. My plugin would benefit from this Smile

-Jonathan


- jingai - 2010-07-25 17:57

Created TRAC ticket for the problem.

Am also looking through the source to see if I can't figure it out myself.

-Jonathan


- Nuka1195 - 2010-07-25 20:20

yes i think it is a bug.

good luck, i had no luck disbaling the progress bar. it would just crash xbmc, even removing it entirely, but that was a while ago.


- elupus - 2010-07-28 00:36

Try now again.. The performance aught to have been improved in trunk. (not dharma yet)


- elupus - 2010-07-28 00:37

Will give that sample some testing thou.


- jingai - 2010-07-29 00:03

elupus Wrote:Try now again.. The performance aught to have been improved in trunk. (not dharma yet)

Sorry, problem is still there with r32267. Sad

Which commit was supposed to fix it?

-Jonathan


- elupus - 2010-07-30 01:56

It's now fixed in svn. Thanx for the nice test script. Made things oh so easy to figure out, and showed other bugs aswell.