Posted Tuesday, March 7, 2006 @ 15:24:13  

I looked further; firstly, I saw that a simple jtable with a moveable cursor-based data model (I copied out of a book) gave pretty much the same bad results. Then I coded up a much cruder jtable program using just a 2 dimensional object array, where the refresh consisted of java code to 1) issue the select statement 2) a for loop to load the resultset into an object array and 3) display jtable. This worked just fine;i.e. stayed under 10% always and under 2-4% most of the time. I therefore presumed that the culprit must be fancy jdbc cursor useage.

So I tried the same crude approach as described above with quicktable using an object array refresh and it works, almost. What happens is that for the first 15 to 20 seconds of display, quicktable's cpu utilization oscilates between 10 and 40%, then goes down to the under 5% level except for a blip every 20 or 30 seconds up to 20-30%.

I have several questions.......

1. Why, when using quicktable with constantly updated object arrays is there the high cpu utilization for the first
20 seconds;

2. what is causing the 20-30 second blip in the object array refresh as described above?

3. Is my observance that jdbc cursor useage, (at least for this circumstance), is a huge cpu resource hog
correct??
-if so is there any way, without source code, to force quicktable to not use cursors?? I assume it must
be able to run not using cursors in order to handle older drivers that dont support it.

I repeat my satisfaction to date with quicktables. Thanks for the very useful product.

Posted Wednesday, March 8, 2006 @ 13:56:54  

First, to answer your questions....

1. quicktable version 2.0.5.24, which unless youve updated in the last month or so is I believe the latest.

2. jsbc driver = microsoft sql server standard jdbc driver

3. microsoft sql server express, which Im trying out for the first time (so far I am begrudgingly pretty impressed)

4. jdk is 1.4......

5. using select query via setSelectSql();

6. I am selectng the top 500 rows of a 250000 row table (top =highest event sequence number, which is the primary key).

7. Ill send the code if this turns out to really be a quicktable issue, or if you want it anyway let me kow.

What Ive discovered so far....
1. using a jframe instead of internal frames doesnt do much; slightly better I think, but its not the issue.

2. I tried firebird/jaybird (latest stable version as of december) and got pretty much the same results; actually
slightly worse but I didnt spend much time tweaking, and may not have done the "limit 500" just right). I can
also try hsqldb and/or mysql if I have to.

3. Whats got me confused and self-doubting is that I made up a 500 record test table so that I could
eliminate the "top 500" phase out of my selectsql. When I did that, but still refreshing every 1.5 seconds, it worked; way under 10% useage always!!. I even made up a change simulator that would change records, adding and deleting a few every second so that the data was dynamic. Everything was still fine; way under 10%.
That says this might have something to do with the huge total size of my table; somebody somewhere (the db server, jdbc, quicktable, or a stupidity on my part) must be retreiving the entire table or something.

So, lets not go digging into quicktable quite yet. I need to check out a few things with my sql, my big table, expanding java memory space, etc first before I waste your time.

Thanks for the quick reply; Ill let you know what I see.

Posted Wednesday, March 15, 2006 @ 20:44:56  

However I still see a 20-30% cpu useage for this quicktable screen, and after further experimentation,
including trying java 1.5, I suspect it has to do with the fact I am using JInternalFrames. What I see is..

a. If I change the screen to a jframe, then no problem; normal cpu useage is well under 5-10%.

b. with Quicktable using JInternalFrames I dont have to be doing continuous refreshes to get this problem; just having the quicktable screen visible and refreshes stopped seems to cost me 20% of my cpu.

c. I made up a simple jinternalframe quicktable array screen that just displays a 10x10 unchanging array of "fubar" strings and that alone will continuously use up 15% of my cpu until I hide the screen.

d. None of my non-quicktable screens, (including a couple of jtable screens I haven't converted to quicktable yet) have this problem (all under 5%).

So my question is; is there anything unusual happening in quicktable when it is running in a JInternalFrame??
A couple of previous threads alluded to forced garbage collection, but from what I read only on closing; My issue is more continuous; I can make the 20% cpu jump come and go just by hiding/unhiding the quicktable screen with another screen.