[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: KDE/kdelibs/kate/view
From:       Milian Wolff <mail () milianw ! de>
Date:       2010-12-15 14:39:23
Message-ID: 201012151539.23849.mail () milianw ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Christoph Cullmann, 15.12.2010:
> On Wednesday, December 15, 2010 12:17:00 am Dominik Haumann wrote:
> > On Tuesday, 14. December 2010, Milian Wolff wrote:
> > > Pascal Létourneau, 14.12.2010:
> > > > SVN commit 1206542 by pletourn:
> > > > 
> > > > Optimization:
> > > > Clear selection range (it's moving range) before removing text
> > > > 
> > > > BUG:259879
> > > > 
> > > >  M  +4 -1      kateview.cpp
> > > > 
> > > > --- trunk/KDE/kdelibs/kate/view/kateview.cpp #1206541:1206542
> > > > @@ -1783,11 +1783,14 @@
> > > > 
> > > >    m_doc->editStart ();
> > > > 
> > > > -  m_doc->removeText (m_selection, blockSelect);
> > > > +  // Optimization: clear selection before removing text
> > > > +  KTextEditor::Range selection = m_selection;
> > > > 
> > > >    // don't redraw the cleared selection - that's done in editEnd().
> > > >    clearSelection(false);
> > > > 
> > > > +  m_doc->removeText(selection, blockSelect);
> > > > +
> > > > 
> > > >    m_doc->editEnd ();
> > > >    
> > > >    return true;
> > > 
> > > This would probably also be "fixed" by making the revision history
> > > slimmer for this case, i.e. don't store one item per removed line but
> > > just one item that removes all in one go.
> > 
> > And maybe this should even be covered by a unit test? If the performance
> > penalty is that big, it's probably just a matter of time until someone
> > comes and changes the code accidently again. On the other hand, we'll
> > never have unit tests for everything, so maybe this is just a wrong idea
> > ;)
> 
> Actually the revision history has nothing to do with this performance
> impact, only that the range must be touched the whole time for each small
> change, which is not related how to store the changes for the revision
> history which is btw. not used in kate part itself at all ;)

Still, couldn't it be optimized to change the range *once* instead of over and 
over again? I know that we'll have this problem in KDevelop probably. Or well, 
maybe I work-arounded it everywhere nowadays by removing the ranges contained 
in a remove-edit.

Bye
-- 
Milian Wolff
mail@milianw.de
http://milianw.de

["signature.asc" (application/pgp-signature)]

_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel


[prev in list] [next in list] [prev in thread] [next in thread]