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

List:       kde-bugs-dist
Subject:    [Bug 218261] Kdevelop is unusable (too slow) when project is stored
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2009-12-12 1:42:11
Message-ID: 20091212014211.EEB4B2B9C7 () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=218261





--- Comment #8 from Andreas Pakulat <apaku gmx de>  2009-12-12 02:42:10 ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > Whenever reparsing a file, kdevelop has to check whether any of its hundreds of
> > > > includes has changed. And if it decides to reparse a file, then it has to
> > > > search for all "#include"ed files within all include-paths.
> > > > 
> > > > Both of these are probably the reason why it is so slow on your remote
> > > > filesystem. There is not much that can be done here, as both of these steps are
> > > > required. The filesystem could do some caching to speed it up.
> > > 
> > > I don't see a reason why you'll want to reread all includes every time. 
> > > I think it can solved pretty easily:
> > > Let's say we have some source and header files open. When we update the header
> > > files, just schedule reparsing of all other open files (or only files that
> > > depend on currently edited header if it's possible) - start reparsing when user
> > > switches tab to other file.
> > 
> > Sorry but that doesn't make any sense at all. If you change file X, the parser
> > needs to reparse it. And reparsing means checking all the #include'd files to
> > see wether they changed in the meantime. Else the parser will have outdated
> > information on the code and present wrong assistants, do wrong refactorings and
> > present wrong errors. I'm seeing that sometimes with eclipse and its a major
> > annoyance when I have to help it get the updated file contents right.
> > 
> > Working on big projects over remote connections and expecting a fully-fledged
> > IDE to handle that gracefully and as fast as local storage is just unrealistic
> > dreaming. Either transfer your project to a local storage or use a plain text
> > editor.
> 
> I don't see your point. You're working on a project and you're editing file X,
> which includes file Y. You've changed few lines so X need to be reparsed, but
> why do file Y need to be read again (can't it be cached?)

Actually nobody said it would be re-read. We've said we're checking wether it
needs to be re-read. That means a stat on each #include (recursively through
the whole list) each time you edit the file. And a stat is already pretty
expensive on remote filesystems. Caching of the content is not really needed
(or rather is already done, in the parsed form).

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]