[Kst] branches/work/kst/1.5/kst/src/libkstapp

[arwalker at sumusltd.com]

But this doesn't give me any actual numbers. The previous approach was
to simply clear the entire contents of the dialog and repopulate. How do
the two compare in terms of real speed for some reasonable number of scalars?
I would imagine my changes are slower but how much slower?

We can certainly change the name of the remove() API. I'm not sure that
"horribly convoluted" is an argument against committing code.

On Thursday 12 April 2007 12:06, George Staikos wrote:
> On 12-Apr-07, at 2:35 PM, arwalker at sumusltd.com wrote:
> > Could you provide some data on how slow this will be for how many
> > scalar
> > values (only when the dialog is open of course - as it doesn't
> > update when
> > hidden)?
>
>    Unless I'm missing something, it's O(n^2) with slow operations on
> every update - dynamic casts and repaints - and a very large constant
> factor.  Furthermore it took me over an hour to decipher what was
> going on in this patch.  It's horribly convoluted.
>
>    Also remove() is a poor API name.  It doesn't indicate at all what
> is happening.
>
> > Do you feel that no dialog is better than a dialog that is
> > functional but updates more slowly than previously?
>
>    Yes absolutely.  It's not the dialog slowness that is the
> concern.  It slows down all of Kst.
>
> --
> George Staikos
> KDE Developer				http://www.kde.org/
> Staikos Computing Services Inc.		http://www.staikos.net/
>
>
>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst