[Design 2003][TableView] Performance issues

[guillaume-hrc]

Hi,

We have developed an application with <b>tableView & Iterator</b> where I placed <b>HTML <input> fields instead of HTMLB InputField</b> so as to manage events <i>onChange</i> and <i>onKeyDown</i> with customer-specific JavaScript. We are talking about 300-400 <inputs>.

The problem we are facing is when we switch between those <input>, we have a "latency" time of up to 5-6 seconds (especially when we use the TAB key instead of clicking on the target cell).

If we switch the application to Design 2002, there is no such problem. Consequently, <b>I made the assumption that some new HTMLB client-side events</b> are causing trouble... ?

Some of my colleagues point out that it could be due to new large CSS files

Many thanks in advance for sharing your ideas on this problem!

Best regards,

Guillaume

[Former Member · Accepted solution]

Hi,

use the visibleRowCount and footerVisible attributes to limit the number of rows/cells rendered. It solved performance probelms to me.

Regards

[guillaume-hrc · Accepted solution]

Hi Sebastian,

Unfortunately, I need the whole lot of <input> to do some processing (in a way, it is quite similar to a worksheet).

Thanks.

The problem is more like : "Do we really have to give up on Design2003... or is there - at least - a way to disable the overhead due to it"

Best regards,

Guillaume

[Former Member · Accepted solution]

Hi again,

did you try delta-handling ?

[guillaume-hrc · Accepted solution]

Hi,

Well, I don't think it applies in our case but if you have some info on this, I will gladly have a look at it !

Best regards,

Guillaume

[Former Member · Accepted solution]

Sorry I mixed something up - delta handling is to reduce traffic but not client rendering. I think the browser gets too many elements to handle and stucks.

Regards

[thomas_jung · Accepted solution]

Actually I have seen Delta Handling both help and hurt the client side rendering time. You see when using Delta Handling, the entire page is not rebuilt in the browser - hence the flicker free effect. New elements and data are infused into the page DOM using JavaScript. However the entire page does have to be compared with a Delta Version (held in a hidden frame) to determine what has changed.

On a very large complex page this comparison can be costly. However this can be reduced by using DH Blocks.

Now with a very large table, you might just have to test it and see what happens. The overhead of comparision on the large table might be very costly. Then on the other hand, if only a few cells actually change, the savings of using DH might be worth while.

The rule of thumb with DH - try it. If it works and it doesn't slow things futher - go ahead and use it. If it breaks anything - Don't use it.

However there probably isn't any magic bullet that will solve performance problems with a very large table. That is why we have table pagers. Realistically how much data can the user reasonably look at on one page anyway.

[guillaume-hrc · Accepted solution]

Hi Thomas,

Many thanks for your explanation. I will try!

By the way, any idea on the switching effect between <input> in Design 2003... ?

Thanks again.

Best regards,

Guillaume

[thomas_jung · Accepted solution]

Sorry I'm not sure that I understood the question:

>any idea on the switching effect between <input> in Design 2003

[guillaume-hrc · Accepted solution]

In fact, the question in the first place was about <b>the slowlyness of going from one <input> field to another</b>, <u>without even inputting any values</u>, either by clicking or by using TAB key.

We observed that the simple fact of clicking to another cell (without any server-side event) requires much more time in Design 2003 than in Design 2002.

We were wondering whether this was due to new large CSS files or from the new events on the tableView (the onClick on the <table> for instance).

Best regards,

Guillaume

[thomas_jung · Accepted solution]

I have never built a table so large that I noticed the effect you are seeing - so I can't say for certain. On the other hand, I'm not sure it matters. Either cause would be within the UR framework itself and untouchable.