CPU usage is still very high when the page with 18 tables finishes loading

I found a very weired problem. When 18 tables (each has 50-100 rows) are being created on the client computer on one page, I found CPU usage is about 90%. That's fine, since a lot of calculation have to be done, but I think this status should be temporary. My problem is that after all tables have been created and the whole html page loaded, CPU usage is still very high, close to 90%. I don't know what's going on here, because at this point, nothing else should be running. But if I click the other links, cpu usages will be decreased to 0-10%. Lib is still running and doing something after tables created? Is there any functions I can used to release resources occupied (CPU)?

Thank everyone.

The library should not do anything after the grid is created and toolbar size is adjusted (this normally happens with 0.5 sec delay). Does CPU usage grow incrementally with the number of tables or there is some threshold after which it jumps to 90%?

Yes, it's weired. I'm using jsp to create data from server side and the tables are created based on the data. I found in some cases, if many tables (?20) created on client side, cpu usage will be very high and still high after tables have been created.

BTW: I have been able to reproduce this as well.

- CPU at 20% after loading
- using the edit cell template with text, calendar, select box
- 4 grids on page
- one grid with 50 rows and 30 columns
- other grids less than 10 rows with ~ 20 columns

I am thinking this has to do with IE continually monitoring for all the events on the divs (for edit template)...

Anyone else?

I'm getting the same problem using the ActiveWidgets Grid object. The CPU utilization steps with the number of grids on a page. If I have a few grids on the page, the CPU utilization becomes 90+% and remains there.

I also think it has to do with IE continually monitoring for the events, but I don't know of a way to fix this.

If you have a high CPU usage, look to see why it's high. I have a page that has 5 grids on it with two of them having over 150 rows and the CPU utilization for IE is 0%. Just because you have a high CPU usage and you are currently using IE doesn't mean that IE is what is using up the CPU. When you are in the Task manager, click on the Processes tab then click on the CPU column twice to sort with the highest usage on top and see just what IS taking up your CPU. On my system, I found that a defrag program by Microsoft was using almost 100% (HELPSVC.EXE), I killed that service and my system works great now.

Jim,

I am using IE, and the Page Fault Rate is consistently at 600 ps when viewing the grid. (for IExporer.exe).

This is going to make it unusable in an environment like citrix.

I just tested this and found no problems, that was with a grid using ajax and server sorting.

I think it could be some other code in you page or a patch you are using maybe. Might be a good idea to confirm if it is javascript code been run as well that is causing the cpu load try using

View->Script Debugger->Break at next statment

If you dont' have this download and install the script debugger from the microsoft site

Everyone, please post your name so I know who it is that I am replying to.

For the person that said that their Page Fault rate was high and that you are using IE? I wasn't aware that IE worked on Linux. And if you aren't using Linux then where are you coming up with a page Fault Rate for Windows? Or are you using a Mac?

I use many grids on one page in Windows, using IE 6.0 and once the grids are drawn, the CPU usage drops to 0. IE does not monitor for events, they are triggered via user actions or system events.

Right now I doubt if it is the grids that are causing the problem.

I am experiencing a similar issue. I didn't notice on my machine until I checked the "performance" tab in Task Manager. IExplore.exe uses 100% of the CPU after the grid is loaded and I select a row.

I have a master grid with a "selectionChanged" event set to trigger when a row is selected. It then populates some other IFRAMEs and grid controls with XML. It seem that the CPU usage pegs at 100% once I select a row in the parent. I verified that the "selectionChanged" event fires only once, so I have no other explanation.

Once I navigate away from the page, the CPU usage drops down to normal.

Any ideas? I am using v1 of the Grid component.

I have narrowed the problem down to this function I wrote:

/*
  **  Fills the specified grid with the specified XML string.
  */
  function doPopulateGrid (oGrid, sXML) {
    
    // Create ActiveWidgets data model - XML-based table
    var table = new Active.XML.Table;
    
    // Provide data XML
    table.setXML (sXML);
    
    // Provide external model as a grid data source
    oGrid.setDataModel (table);
    oGrid.refresh ();
  }

It seems that the last line, "oGrid.refresh ()" is where the CPU usage occurs. If I comment out that line, the CPU usage never hits 100%, but of course my grids don't update either! :(

Am I doing anything wrong here?

Any help would be greatly appreciated -- I am trying to finish a project that's way overdue!

How often are you calling this function?

I see in above posts that you know that this only fires once. I don't use XML as a JavaScript array is faster so I went that route. Have you tried to use a JS array instead of XML to see if that might clear up your issues? It would be worth a test.

I think original issue is also related to this bug:

http://www.activewidgets.com/javascript.forum.8473.0/bug-high-cpu-usage-with.html

My web-app is XML-centric, so I prefer to use XML to update my grids. I've found the speed tradeoff is minimal for my use.

I fixed the issue in my code until Alex can come up with a better bugfix in the AW lib itself. Here's what I do:

1. Update the grid data in the "hidden" grids as needed. I use the "setXML()" method, but updating a JS array would work as well.

2. Call the "refresh()" method of the "hidden" grids only when they come into view (triggered by my custom tab control).

This solves the CPU hogging issue and also sped up my app tremendously as I'm not calling "refresh()" on all the hidden grids at once.