KDevFileManager performance

[Adam Treat]

Hi!

Can we please put off this discussion.  There are bigger problems with the 
project API(s) and they'll need to be completely refactored I'm afraid.  This 
is what currently happens:

KDevProjectController is the controller, but all it really does at the moment 
is handle loading/unloading the KDevProjectManager_part.  
KDevProjectManager_part is the view, but it calls the importers to populate 
the data in a 'model'.  This model really isn't a model at all.  It needs to 
be rewritten to inherit QAbstractItemModel.

Now, this is what _should_ be happening:

KDevProjectController is the controller and it should behave as such.  The 
controller should be primarily responsible with populating (via the 
importers), updating and changing the project model.  This model should 
inherit QAbstractItemModel.  The KDevProjectManager_part should only be 
responsible for displaying the model.  The only other thing it should do is 
respond to user requests by forwarding those requests on to 
KDevProjectController which should then update/change the model in accordance 
with the user's requests.  That is how it should happen.

Note that this isn't only the project API(s).  The way KDevDocument is handled 
is similarly messed up at the moment.  Right now KDevDocumentController 
behaves like a true controller, but it stores it's data in QHash(s).  It 
should directly populate a model that inherits QAbstractItemModel.  
KDevDocument should be made to inherit KDevItemCollection and so on...

And then the DocumentView part should only be responsible for displaying the 
model and forwarding on user requests to KDevDocumentController.  Right now, 
DocumentView tries to capture all the signals of KDevDocumentController to 
populate it's own model.  The view is playing intermediary between the 
controller and the model.  Bad!

So, as you can see all of this needs to be reworked.  I have plans to do so, 
but there are just so many things to do right now.

Adam

On Thursday 17 August 2006 3:57 pm, Andras Mantia wrote:
> Hi,
>
>  I'm worried about the performance problems in the KDevFileManager
> class, due to the KDevProjectItem* way of storing the data. If these
> classes help later with the model/view stuff, I have no problem with
> them, but due to their tree-like structure it is hard and time
> consuming to work with them. For example if you want to get all the
> files that were added to the project, you would need to go through this
> structure using a recursive method. To find if a url was already added
> or not, you would have to do the same. To get information about the
> item, again, a search through all of the items.
>  For this reason I have a suggestion, which is to move allFiles from
> KDevProject to KDevFileManager. The reasoning is that this way I could
> implement a file manager which stores the URL->KDevProjectItem* mapping
> in a QHash or QMap and it will be much faster to retrieve all the
> above. allFiles could have access directly to this map, inProject could
> get the QList of allFiles and find there the URL and so on. It would be
> even more better if allFiles would return a QHash<KUrl,
> KDevProjectFileItem*>.
>
> Comments?
>
> Andras