[bt-devel] Excessive CPU consumption during module install

[Troy A. Griffitts]

I might be able to do something about this.  I believe I can have a 
static SWMgr::cache which stores a hashtable of <path, SWMgr> pairs and 
if you ask for the same SWMgr again, the new SWMgr can use a common 
SWConfig.  We might need to be careful about reloading after install new 
modules-- we've have to flush the cache, but we already have an 
SWCacheable object with the correct methods, so we can expose a standard 
way to do this.  Let me know if you find an easy solutions, otherwise, 
if I don't hear from you, I'll try to make some time over the next 
couple days to work on this.

	-Troy.



Martin Gruner wrote:
> Eeli,
> 
> can you do something about this?
> 
> mg
> 
> Am Dienstag, 7. Juli 2009 22:30:06 schrieb Greg Hellings:
>> Jaak,
>>
>> On Tue, Jul 7, 2009 at 2:47 PM, Jaak Ristioja<Ristioja at gmail.com> wrote:
>>> Hi!
>>>
>>> I've been able to reproduce this with 2.0.1. Here's part of a backtrace
>>> for this situation:
>>>
>>> #0  0x00007fa2a733fe2c in sword::FileDesc::getFd () from
>>> /usr/lib/libsword-1.5.11.so
>>> #1  0x00007fa2a732e9cc in sword::SWConfig::Load () from
>>> /usr/lib/libsword-1.5.11.so
>>> #2  0x00007fa2a732f5e1 in sword::SWConfig::SWConfig () from
>>> /usr/lib/libsword-1.5.11.so
>>> #3  0x00007fa2a7332c3e in sword::SWMgr::loadConfigDir () from
>>> /usr/lib/libsword-1.5.11.so
>>> #4  0x00007fa2a7339fae in sword::SWMgr::Load () from
>>> /usr/lib/libsword-1.5.11.so
>>> #5  0x00000000004e6bcc in CSwordBackend::initModules ()
>>>
>>> #6  0x000000000055957e in instbackend::backend ()
>>>
>>> #7  0x0000000000560209 in BtInstallThread::BtInstallThread ()
>>>
>>> #8  0x0000000000562049 in
>>> BtInstallProgressDialog::BtInstallProgressDialog ()
>>>
>>> #9  0x0000000000564fea in BtSourceWidget::slotInstallAccepted ()
>>>
>>>
>>> It appears that the BtInstallProgressDialog constructor creates a
>>> BtInstallThread for every work selected to be installed. The
>>> BtInstallThread constructor calls instbackend::backend, which calls
>>> CSwordBackend::initModules(), which calls sword::SWMgr::Load(). The
>>> latter method takes most CPU time. Multiply that time with the number of
>>> works selected and you got a huge delay.
>> That definitely sounds like it is the source of the problem.  I'm
>> guessing that is done so that the download and install can be executed
>> in parallel.  Someone more familiar with that... is there a reason why
>> we can't use a single thread to do the installs while another updates
>> the GUI?  Is parallel downloading and installing actually what's going
>> on, and it is worth the performance increase?  It sure doesn't seem
>> that it is, to me!
>>
>> --Greg
>>
>>> Unfortunately I'm not familiar with the code, so I have been unable to
>>> produce a fix. I hope you'll figure this out before 2.1. :)
>>>
>>> Blessings!
>>> Jaak
>>>
>>> _______________________________________________
>>> bt-devel mailing list
>>> bt-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/bt-devel
>> _______________________________________________
>> bt-devel mailing list
>> bt-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/bt-devel
> 
> 
> 
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel