[Kmymoney-devel] KMyMoney - Sluggish Response

[Cristian Oneţ]

On Fri, May 14, 2010 at 2:46 AM, aga <aganderson at ukonline.co.uk> wrote:
> On Thursday 13 May 2010 06:08:00 Cristian Oneţ wrote:
>> În data de Miercuri 12 Mai 2010 00:26:45 David Houlden a scris:
>> > > Is there a general sluggishness now?  On v1, saving an edited cleared
>> > > status happens 'in the blink of an eye', whereas on svn the window
>> > > clears for perhaps 1 1/2-2 seconds while it thinks about things.
>> > > Accepting outstanding schedules is accompanied by much screen updates,
>> > > and even when saving a transaction there is a noticeable pause.
>> > >
>> > > I've only seen a mention relating to keyboard use, not of a more
>> > > general issue.  Bugs obviously have top priority, and removing KDE3
>> > > too, so responsiveness has to take a back seat, but I just wondered
>> > > what the thoughts are on this.
>> > >
>> > > Don't take this as a complaint!  You guys have accomplished a
>> > > tremendous amount on very tight, ambitious  schedules, and I'm
>> > > extremely impressed.
>> > >
>> > > Allan
>> >
>> > Hi,
>> > I think there are some issues with performance, particularly around the
>> > ledger  even when using a release build not debug. I have definitely
>> > noticed that just clicking on an entry to mark it cleared causes a screen
>> > refresh which is very slow. It doesn't seem to matter how many entries
>> > are in the ledger.
>> >
>> > My test KDE4 machine is a fairly slow 1200MHz pentium III and it is quite
>> > interesting to watch how some of the screens refresh. Allan mentioned
>> > entering schedules and when overdue ones are entered at startup there
>> > does seem to be a lot of screen redrawing going on. I've also noticed
>> > that when switching to the institutions screen it appears to get drawn
>> > twice, first slightly further down the screen to where it should be and
>> > then again in the  correct position.
>>
>> I've committed some changes that should at least improve the visual aspect
>>  of all this. That means it may not be faster but it should look better
>>  because some screen updates while loading the register where eliminated.
>>  Unfortunately we can't change the fact that the register is re-loaded at
>>  every data change operation without some major re-writing. But the plan is
>>  to get a stable KDE4 release, without Qt3 support, with the same features
>>  as the KDE3 version and release that so people can have something usable.
>>  After that we can throw out the bad concepts like reloading everything at
>>  every small change and start from scratch but that will take a lot of time
>>  (which we are very short of). We try to do out best with the existing
>>  codebase so keep sending your valuable feedback.
>>
>
> Hi Cristian
>
> I'm now on svn1126445.  Contrary to what you suggested, that's a big
> improvement in speed!  Editing the cleared status happens much as in v1.x.  So
> far as entering schedules at startup is concerned, that, too is much faster,
> although the window bounce is still as frantic.  If anything, it might, on a
> rough timing test (me counting as fast as I can), be marginally faster than
> v1.x!  Entering/accepting an edited transaction cause just one slow bounce!
> That's all I've looked at so far, but I suspect new users would not think
> there's a problem, apart from the bounce, that is.

I've figured out the source of all that bouncing and, if I'm lucky, I
can get a fix into SVN before the release. We just need some updates
disabled while the transaction is being entered (that is when the
dataChanged signal is emitted). I'm glad that there is improvement in
this area.

Regards,
Cristian