InfoQube IM - Community

Submitted by Armando on 2010/02/24 01:38

[Moved this thread to the bugs section]

There seem to be performance problems with (some?) auto-assign equations.

Here's a function I'll use in my example:

Function CheckYNField (StringVar,field)    
  if instr(field,StringVar)>0 then
    CheckYNField = -1
  else
    CheckYNField = 0
  end if
End Function

(What it does is basically giving back a -1 value if a certain string is found in a field -- this value can be used to check/uncheck Boolean Y/N fields.)

I've been using this equation in at least 2 different ways to obtain the same results... but with big performance differences !

1- In the first way, I've used the function in the row equation section of a field (field management dialog).

E.g. : In the Contact field I have put in the row equation section :

CheckYNField ("xCON-",TypeDocBib)

So that when I write "xCON-" in the TypeDocBib field, the contact field is instantly checked.

2- to achieve the same thing, I could also have a similar equation in the auto-assign section of the TypeDocBib field.

E.g. : In the TypeDocBib field I have, in the auto-assign section :

AME:Contact=CheckYNField("xCON-",TypeDocBib)

So that -- exactly like #1 -- when I write "xCON-" in the TypeDocBib field, the contact field is instantly checked.

Now... I tried putting several auto-assigns rules using the CheckYNField() function in the TypeDocBibTypeDocBib field

e.g. :

AME:Contact=CheckYNField("xCON-",TypeDocBib)

AME:Task=CheckYNField("xTAE-",TypeDocBib)

AME:Projet=CheckYNField("xPJ-",TypeDocBib)

etc.

but then, everytime I write something in the TypeDocBib field it takes a looonnnnggg time for IQ to process the info in the TypeDocBib field and check the appropriate Boolean fields.

So... I reverted to the first solution (#1).

With solution #1, when I write something in the TypeDocBib field, the computing is almost instantaneous, even if there are several fields in which the

CheckYNField("SpecialString",TypeDocBib) is involved.

Questions :

1- Why is there such a performance difference ?

2- Is it normal (or could it be optimized) ?

3- Does that mean that Row equations should be favoured ? (Yes, some things might be a bit harder to achieve with Row equations, but if the performance is that much better, it's probably worth it...)

Comments

Humm... How many such rules do you have ? Do these fields (Contact, Task, etc) also have rules / equations ?

In a fresh sample database, I added the fields and rules and it runs instantly.

[quote=Pierre_Admin]

Humm... How many such rules do you have ? Do these fields (Contact, Task, etc) also have rules / equations ?

In a fresh sample database, I added the fields and rules and it runs instantly.

[/quote]

I had about 9 similar rules (as I said, I reverted to the other strategy -- a bit harder to follow the scripts' ramifications, but faster) . But there could be other factors.

e.g. (without the "AME : myfield=" part):

CheckYNField ("xMO-",typeDocbib)
CheckYNField ("xTAE-",typeDocbib)

CheckYNField ("xPJ-",typeDocbib)
CheckYNField ("xOBJ-",typeDocbib)
CheckYNField ("xDF-",typeDocbib)
CheckYNField ("xCON-",typeDocbib)
CheckYNField ("xJO-",typeDocbib)
CheckYNField ("xRL-",typeDocbib)
CheckYNField ("xCO-",typeDocbib)

If you don't see any obvious performance divergence, don't loose time on that one. I could/can reproduce it here, but my DB has also lots of other things happening.

We could look at it on my computer at some point. It would probably be more efficient.

Thanks !

Hi Pierre,

I'm bringing this issue back on the table even if I know that this will be taken care of in another development phase -- maybe you could add these important notes somewhere for later ?

Here are 3 of the issues causing pretty major slow downs in my DB (there are other seemingly related issues I won't mention for now):

1- Auto-assign rules. I know for sure that auto-assign rules slow down items creation by quite a lot in my DB. Anytime I have many (see previous posts) auto assigns "involved" in some item creation, item creation/modification/displacement takes between 1-2s (for each item). This slows down operations by quite a lot (one item is no big deal, but multiplied by 100 or more it becomes a significant problem).

--> seems to be related to the number of fields in the DB using equations and rules (if I delete many fields with rules and equations, performance increases... Even if those fields weren't "used" in the cases where other fields were directly involved in poor performance.)

2- Inheritance rules. Inheritance too is also slowing down DB operations quite a bit -- same problem.

--> seems vaguely related to the number of items in the DB, and the number of fields using inheritance.

3- Erasing item(s). This has been going on for a long time already. I always have to wait between 5s and 9s for the "Erase" dialog to appear.

-->seems to be linked to the size + number of items of my DB (even when only deleting one item)

The problem is that these problems (especially #1 and #3) don't seem to noticeably affect speed in a new DB.

I also tried copying my own DB and deleting all items, most fields, most grids, user code, etc. and performance is only marginally better... Which is intriguing : when almost everything is gone, what could be affecting performance ???

Hi Pierre,

All the above mentioned problems are still valid. I just redid some testing.

For acceptable performance in my DB I'd have to :

1- remove most inheritance rules (I might be working on that tomorrow, but it's not the kind of solution I wanted)

2- remove most auto-assign rules of certain types. Seems that simple ones involving Y/N fields aren't too taxing, but must others really slows down performance by quite a bit.

Removing this (see below) in one of my auto-assign rules + removing inheritance for that same field noticeably improves performance

A:WIKITag=AddKeyword(WIKITag, "tgsPSoPe") |
A:WIKITag=AddKeyword(WIKITag, "tgsPScHu") |
A:WIKITag=AddKeyword(WIKITag, "tgsPPsTh") |
A:WIKITag=AddKeyword(WIKITag, "tgsPpsye")

My computer is getting very hot from all that processing...

Mantis :

0957

General performance problems caused by 1-inheritance and 2-certain auto-assign rules