Dear Tobias,
I can have a look at optimizing getModuleStatus. I can certainly see
that only checking locally installed modules might be a speed
improvement, but I suspect most of the time is loading all the .conf
files for each module, and that is done when constructing the SWMgr
(remote and local). SWORD previously worked with a single modules.conf
file where the section was appended each time a module was loaded. It
still will work in this manner. I might try dumping all the .conf files
into a single cache.conf file and using that for reading the info of a
remote repository-- which can include thousands of individual .conf
files. We can see if that speeds up this operation.
On 10/30/22 08:49, Tobias Klein wrote:
Hi Troy,
When integrating the module update functionality in Ezra Bible App, I
noticed a performance issue in the function InstallMgr::getModuleStatus.
On my laptop, it takes almost two seconds to run this against all
repositories from the master repo list. On my slower surface tablet,
it takes even longer and I haven’t tested it on my even slower Android
devices, yet. This generates a bit of an issue in my JavaScript based
application (longer interrupts of the JavaScript event loop lead to
some freezing in the UI).
Considering the parameters constSWMgr &base, constSWMgr &other, I saw
that the function loops through all modules within other. If one just
wants to see which local modules are outdated, it would be enough to
go through the ones that are also present within base, right? Could
that be a way of optimizing the performance?
Best regards,
Tobias
_______________________________________________
sword-devel mailing list:sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page