[Eric] What am I doing wrong in 4.0.1 (speed issues)?
jUrner at arcor.de
Sat Aug 11 18:29:00 BST 2007
Detlev Offenbach wrote:
> On Samstag, 11. August 2007, Mike C. Fletcher wrote:
>> Detlev Offenbach wrote:
>>> On Montag, 6. August 2007, Andreas Pakulat wrote:
>>>> On 06.08.07 17:04:04, Mike C. Fletcher wrote:
>>> Eric4 actually just populates the model with all the files contained in
>>> the project file. Everything else (like parsing a file to show classes
>>> and members) is done on-demand.
>> Then, something weird is going on. I am seeing about *5-8 seconds* to
>> expand the tree branch for directories with a couple of dozen files
>> (i.e. items that should already be in the model) in reasonably large
>> projects. Something is taking an enormous amount of time to make a
>> machine this powerful run that slowly. The same slowdown is seen every
>> time the tree view is refreshed AFAICS, e.g. when switching files, when
>> opening files etceteras. If the information is all in-memory the access
>> shouldn't be anywhere near that slow, even if all of the code being run
>> is Python.
> I've noticed this as well but couldn't find anything abvious, that would cause
> this delay. Therefore I assume, that it is Qt4 that is causing this slowdown
> by repeatedly querying the model for some data.
> There is delay visible, when a Python file entry is expanded. This is caused
> by the parsing and processing done by eric4 in order to show the classes,
> methods, ...
> In the Others browser, the behavior is different. Directory items are
> populated, when they are expanded.
>> I'll have to see if I can find some time to look into it. The pauses
>> are starting to drive me crazy when I'm working on larger projects.
>> Thanks, and have fun,
Models seem to be quite slow. I was running into troubles with CharTables
displaying more than a few dozen items in a QListView. Had to pull one
or the other ace to get everything up to speed (timer / thread based item
So, best advice is maybe to avoid adding many items in one hop. I use a
scheme where items are added via a iterator, triggered by a timer wich
stopped at any time, for example if the user decides to go somewhere
else. Of cause,
this has limitatins, too.
Another thing is that it's pretty slow to remove items or clearing a
view wich contains
many items. A few hudred items can take one or the other second untill a
is wiped clean.
Third thing I noticed is, pretty much like like Detlev said, that addig
child items dynamically
(and threaded) seems to be the only way to go to get reasonable
when the number of child items is potentially unlimited.
So, it's shurely not the machine wich is too slow. It's more like loads
of work todo for the Qt
guys to get their widgets up to speed.
More information about the Eric