[sword-devel] InstallMgr::getModuleStatus / Performance optimization possible?
Troy A. Griffitts
scribe at crosswire.org
Thu Nov 3 19:13:43 EDT 2022
OK Tobias,
I have a first cut of a caching mechanism for a mods.d/ folder coded up
and pushed to trunk. I have attempted to remove the cache when the
folder is changed (= new module is installed or removed), but I possibly
have forgotten something. Give it a go and let me know if it improves
things for you on your slower devices and we'll go from there.
Troy
On 11/3/22 12:05, Tobias Klein wrote:
>
> Thank you, Troy!
>
> I'd be glad to test any changes you come up with!
>
> Best regards,
> Tobias
>
> On 11/3/22 5:57 PM, Troy A. Griffitts wrote:
>>
>> 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 at crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>
>> _______________________________________________
>> sword-devel mailing list:sword-devel at crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
> _______________________________________________
> sword-devel mailing list:sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20221103/e2de4cf3/attachment-0001.htm>
More information about the sword-devel
mailing list