InfoQube IM - Community

Submitted by Armando on 2009/03/28 16:28

Major problem.

- Creating a new sub-items usually takes about 3-8s (depending on the computer). Isn't that incredibly slow ?

20s-1 min for 6 items. This is a common problem and happens in ALL grids. Creating a top level item is quicker, for some reasons.

- Demoting/promoting an item takes a long time and a lot of CPU power too : 3-6s (depending on the computer) to move an item left/right. Drives me nuts. This is common and happens in ALL grids. Without any exceptions. Moving an item as a sub item can take as much as 6-10s sometimes.

That particular slowness doesn't seem to be too much -- but is still somewhat -- related to :

1- inheritance (tried in grids without any : a tiny bit better but doesn't change much),

2- Use of complex filters (tried in grids without any filter : a tiny bit better but doesn't change much),

3- amount of columns in a grid (tried in grids with 2 columns : a tiny bit better but doesn't change much),

4- user code (seems to affect speed a bit, but not too much)

5- data base size. My database is far from the 2gb limit. It's about 170mb. I consider this small -- especially compared to my other databases... But it seems to somewhat affect the speed of creating, demoting and promoting items

I mention these because they do affect performance overall, but don't seem to create the two debilitating problems mentionned above.

I tried with grids without any filter, option, etc. activated : same amazing slowness.

I've tried repairing, compacting, to no avail.

One thing that could be causing it -- but I don't have anymore time to test that -- are field related formulas, conditional formating, equations, etc. Kinda hard to test without the proper tools though.

It's been like that for a long while, but becoming slower and slower it seems.

Are these performance problems solvable ? They really prevent me from getting things done.

I can send an emptied database on demand.

PS :

Abit less debilitating but could be much better :

- Applying filters in grids is very very slow.
- when working with certain grids containing many columns, everything is pretty slow, even "tabing/moving" between columns. Unfortunately, this is how I want/need to use IQ : With many columns in some grids.

[EDITS : slowness depends on the computer's CPU power of course. I tried on 2 different computer. My 2nd laptop -- 1.5ghz core2Duo, 1year old : 3s to create a new subitem. ]

Comments

I have often thought that there might be a memory use problem, i.e. some cache or other gets filled up, not flushed right, etc. I say this because I've had occassons when IQ has suddenly closed -- dropped out & other times when it slows & other times when things just stop working especially after using it for a while. Unfortunately I can't really document any of these instances but I know they happen & I'm working on a fast computer w boku memory so neither is an issue. There are times when shortcuts stop working, updates have to be ocmpleted with closing / re-opening grid, sometimes closing / re-opening program.

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-1

I think you are correct in your assesssment of memory usage. I wrote Pierre about this some time ago, so it affects many if not alll versions. I called up Task Manager to monitor some periodic slowdowns, especially when many grids are open. I also monitored memory usage when linking many external files. On my machines, the amount of memory used seems excessive. The slow downs appear to correspond to these memory increases. I'm sorry, it has been a while since I made these measurments, so I don't have the figures. They seem to be reproduceaable however. Jon

I'll read this thread in details later on, for now, it is best to limit the number of opened grids to 10 or less at any one time.

Thanks.

Of course these performance issues are probably not affecting everybody... Only those using certain field features extensively, maybe, like I suggested ?

BTW : I almost never have more than 10 opened grids, and some are just other "windows" of the same one -- but maybe is that the same as having another opened one anyway.

This is still a major problem for me as :

1- I can't use IQ if I'm going to take notes when -- let's say -- I'm on the phone (Item creation, promotion/demotion, etc. is way to slow), in a meeting, etc.

2- It's hard to use IQ's outliner if I'm brainstorming as it can't follow my stream of thoughts. 3-6 s to create an item.

etc.

If one is going to create 20 items quickly, as ideas pop up in a conversation or in one's head, 3-6s in between each item is not possible...

(Is there hope for that to improve a lot in the near future ?..... )

For my 4 year-old IQBase, it is approx 0.2 sec. Is this slow performance also present if creating an item in a new grid (and linked new source field)?

I can send you an empty database with all my original grids, etc.

The empty database is a tad quicker.

Like I said in my first post :

- Top level items are also quicker to create. Not the same for sub items.

- it could be my DB, but a repair doesn,t help.

I'll send you an empty DB just now. Creating a new subitem in the "All" grid (no filters, no source), takes about 3-4s. With my current database, it can sometimes take as long as 5s.

(laptop : dual core, 1.8 ghz., bought 2-3 years ago)

[quote=Armando] [snip]

1- I can't use IQ if I'm going to take notes when -- let's say -- I'm on the phone (Item creation, promotion/demotion, etc. is way to slow), in a meeting, etc.

2- It's hard to use IQ's outliner if I'm brainstorming as it can't follow my stream of thoughts. 3-6 s to create an item. [/snip]

[/quote]

Not to belabor the point but, IMO, this is the kind of thing that really undercuts some of IQ's potential uses. To me it's like the printing problem I referenced in the demystifying thread, i.e. there are some basic things that users come to expect. from any program in this genre.

I continually try to use IQ in my daily life, albeit not as busy as some of you, & sometimes find it very frustrating.

In no way does this diminish the incredible flexibility of this wonderful program. I'm just concerned that this sort of thing will limit it's potential in the wider marketplace -- a success I think we all wish for Pierre.

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-1

Sorry to insist Pierre... I guess I'm afraid to wait too long for this (+ the hierarchical "bugs) to be fixed.

I know that the problem has been discussed, but since I just waited 14 min for IQ to become responsive after pasting only 154 items (we're not speaking about millions here...) -- did it the XML way -- I thought I'd mention it.

14 min is like the equivalent of compressing several 100s of MB if not GB of data on my computer (nothing else was running in the background.) And the thing is that I cannot really use my computer to do anything else while the items are being... processed (???). (Cut/copy/Paste 154 items should take a fraction of a second. Creating an item, whatever the rules, the scripts, etc. should not take more than a second. Why would It ?)

This is common. Happens everyday.

As it is now, for the type of usage I foresee, it's absolutely not usable. I'm confident that all the performance problems are going to be solved at some point, but the question is when...

This is hugely important, really, as I estimated that I've been loosing several hours a week for many months, waiting for IQ to do something.

I'm starting to feel a bit stupid and stubborn here...

(And really, the more I look at it, the more I completely stand by my list of the most important bugs... Hopefully they won't be considered too lightly...)

The round trip to the DB for each action probably is a factor also. I'd imagine every new edit is running an insert, update or delete against the backend DB, which will take longer the more rows the DB contains.

If so, perhaps the edits need to be stored in memory and committed only during refreshes. Of course, the goal has been to move to auto refresh, which would make the issue return.

The DB is definitely not the issue. JET 4.0 speed on insert, update, delete is not influenced by database size. Searching text field is somewhat influenced, but quite acceptable.

I examined armando's file, and the issue is related to how IQ handles inheritance (and armando's file has many field with inheritance). It does not scale well right now. His file will be an excellent test to build faster code

Just came back. Thanks.

The weird thing though, Pierre, is that sub item creation is slow even in a grid involving no source, no inheritance whatsoever... But this is what I can notice from my limited user point of view, of course.

OK, I see what you mean. I removed inheritance from all fields in the database and performance is now normal in that empty grid (no source, filter or whatsoever) and empty database. So yes, it really seems to play a role, even when there's no inheritance involved in a specific grid.

I'm now going to try the same, but with my 270MB DB... and report back.

With no more inheritance on any field, the "original" 270 MB database is much faster.

However, there's still some delay when something is written in the item field (so it's not the simple creation of an empty item + another) and another item is created -- I think it's my use code and maybe other stuff.