ThinkingRock Forum

First, I have downloaded the 2.0.1 version of TR, and I love the facelift on the icons. They all look great. It's funny how something that doesn't bring functionality can make the application "feel" more usable. Great job!

I'm not quite sure if this is really an issue or not, but I did want to go ahead and mention it in case others see similar behavior. When typing in TR, I often see the UI become temporarily frozen or hung. This happens when typing in a new actions description or even simply editing notes on an existing action. Does anyone else see this?

Here is the system info from my IDE Log:

Product Version = ThinkingRock 2.0.1
Operating System = Windows 2003 version 5.2 running on x86
Java; VM; Vendor = 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05; Sun Microsystems Inc.

I ran the jconsole profiler and attached to TR while performing some simple tasks, and the biggest thing I notice is that the CPU gets maxed out when performing these simple edits and sometimes the thread count will shoot up by as many as 18 new threads.

Below are a couple of screenshots from performing some simple tasks. Note that my system has 2 CPUs. TR only uses one CPU at a time, so a CPU value of 50% is TR maxing a single CPU at 100%.

1. Creating a couple of new actions from the Projects screen


2. Editing action notes from the Actions screen


The heap also seems to grow quickly. Perhaps using the Netbeans profiler would reveal more of what's going on? I have about 125 active tasks and about 1500 done tasks (data file is 1.3MB). For me this is relatively easy to live with since most of my time in TR is spent looking at tasks, but if others are seeing this too it is probably worth further investigation.

Thanks,
--matt

I second that... the unresponsiveness, in my case, start happening after a while. And it goes back to normal after relaunching the application.

I'm using Mac OS X 10.5.2 with Java version:
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)

I'm having a similar issue. When editing there is frequently a long pause before characters appear. It also happened now after changing a recurrence from based on time to "subsequent." The extra actions that had accumulated in the project tree disappeared quickly, but it was about two minutes before the program was responsive again. I didn't have task manager up, but my laptop fan kicked up to max (I use this as a proxy for how hard the CPU is working).

Product Version = ThinkingRock 2.0.1
Operating System = Windows XP version 5.1 running on x86
Java; VM; Vendor = 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22; Sun Microsystems Inc.
Runtime = Java(TM) SE Runtime Environment 1.6.0_06-b02


The program is beautiful now - and F5 is my new favorite key. Thanks for all the hard work!

I can confirm that too.

First, I know nothing about the netbeans architecture and am more of a web app guy myself, but I downloaded the source code and ran the netbeans profiler focusing on the task of editing the action notes text area just to see what I could find. I'm sure Jeremy would know better about where to look, but in this test I noticed that the object getting created the most was an Object[] and this was happening when ca.odell.glazedlists.impl.event.BlockSequence.addChange() adds an item to an ArrayList. This is called from TR in propertyChange() on the FilterDone class which is getting called by the refresh() thread spawned in the ReviewActions panel. This event seems to get fired 6 times when I add a single character to an action's notes.

Again, I know nothing about desktop UI development, but perhaps text fields should not fire a refresh thread until the text field loses focus (i.e., it's done being changed)? Personally, I would value responsive typing over quick action descriptions, etc., being updated in real time in the project list. I just wanted to provide a little more info (and was curious if I could get TR building in order to profile it), so I thought I would give it a try.

If you would like the memory snapshot I took, let me know and I can email it to you. It was about 2 MB.

--matt

After going to bed last night I realized that perhaps pointing out these details was a bad idea. Profiling by running a quick test and pointing out the first thing I see is poor form, as doing sufficient profiling to find any performance issues would take much more time than a few minutes before hitting the sack. Nevertheless, profiling may be one of the best ways to find out what makes some UI interactions slower when it's done right. Apologies for jumping the gun with that last post.

Hello - I also find the 'face-lifting' of 2.0.1 very enjoyable, and TR in general a very cool application - and indispensable for me now.
But I suffer the same slow responsiveness as stated here, which unfortunately makes TR hard to use for quickly working on todos.

Is there any news on this topic? I would be very happy if that could be resolved.

Thanks a lot for all your work!
Axel

PS as judged from the other posts, it seems to be on multiple platforms, but to be specific, I am using TR 2.0.1 on a Mac OS X 10.5.3 with Java 1.5.

I can not confirm this behaviour on my Linux laptop. I've been running TR for the last couple of days for full days while working sessions of several hours each, without any slow or unresponsive behaviour from TR. So it might be OS-related.

Re-read the topic and I see it is also confirmed on OSX

I'm running:
Product Version: ThinkingRock 2.0.1
Java: 1.5.0_13; Java HotSpot(TM) Client VM 1.5.0_13-b05
System: Linux version 2.6.22-15-generic running on i386; UTF-8; en_US (tr)
Userdir: /home/hpw/.thinkingrock/tr-2.0.1

I'm also finding it very slow indeed, almost impossible to use.

Product Version: ThinkingRock 2.0.1
Java: 1.5.0_06; Java HotSpot(TM) Client VM 1.5.0_06-b05
System: Linux version 2.6.15-51-386 running on i386; UTF-8; en_GB (tr)
Userdir: /home/dave/.thinkingrock/tr-2.0.1

CPU maxes out to 100% as I edit, and I have to stop after 5 or 6 keystrokes to wait for it to catch up. Navigation around the interface is fine, it is just editing an action that is very slow. Editing in the thoughts collector does not show the same problem.

I like to have TR running all the time. Closing it down and starting again seems get rid of the problem.
EDIT: It only gets rid of the problem for a short period of time.

Changing topic background colour also very slow. CPU maxes out at 100% for about 10 seconds.

I've got 381 actions (including 223 done) and I'll be archiving at the end of the month. I'm sure that 381 is not that many compared to power users.

First of all many thanks to the developpers for all the work. David Allen's GTD is good in theory but only a tool like TR brings it to life. I didn't regret a single cent of my 50$ donation so far.

However a solution to the following issues would be worth another 50$-donation :

> I can confirm the slow note editing behavior stated here before.

> The slow editing behavior shows up especially in the "actions"-view. Here, it is not only slow, but also not reliable: Words are sometimes wrapped - the cursor jumps to the end of the notes-field and often characters are dropped (this issue is already described in the topic "Word wrap in Notes field" from user "tomassan" in this forum)

> Editing notes in the "projects"-view is faster and more reliable - but - far less convenient as there is no search-functionality.

> After restarting TR, editing notes in the action-view is remarkably faster for a short period.

> The issues show up on both platforms I use, MacOSX at home and Win2000 at work.

> I have already increased the memory space for java to 256/512mb in the .conf-file on both platforms:
default_options="--fontsize 10 -laf com.sun.java.swing.plaf.windows.WindowsLookAndFeel -J-Xverify:none -J-Dapple.laf.useScreenMenuBar=true -J-Xms256m -J-Xmx512m -J-XX:PermSize=256m -J-XX:MaxPermSize=512m -J-Dsun.java2d.noddraw=true -J-client"

> My current .trx-file size is 1346KB (868 actions/578 done).

MacOSX-configuration (MacBook DualCore, 4GB RAM):
Product Version: ThinkingRock 2.0.1
Java: 1.5.0_13; Java HotSpot(TM) Client VM 1.5.0_13-119
System: Mac OS X version 10.5.4 running on i386; MacRoman; de_DE (tr)
Userdir: /Users/hendrik/.thinkingrock/tr-2.0.1

Win2000-configuration: (Hardware Pentium M Dothan 1.7GHz, 1,5GB RAM)
Product Version: ThinkingRock 2.0.1
Java: 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22
System: Windows 2000 version 5.0 running on x86; Cp1252; de_LU (tr)
Userdir: C:\Documents and Settings\User\Application Data\.thinkingrock\tr-2.0.1

A quick workaround - based on source-code modifying - that works is the following:

Append "setNotesWithoutNotify" in "TR Model -> tr.model.action -> Action.java"



In "TR View - Action -> Source Packages -> tr.view.action -> ActionPanel.java" change "setNotes" to "setNotesWithoutNotify":


The automatic update / refresh of e.g. the search list no longer works after this modification.

FWIW, whenever I experience this problem now I just close the app and reopen it and things seem to be fine for a while if not for the rest of the day. A less than optimal solution, but a fairly quick fix.

I am running latest Java 1.6 on Linux via X and when accessing my desktop via thin client over the X11 protocol the application is unusable it is that slow.

I'm not sure if the above people are using thin client/remote desktop or the like, but for me it destroys the application performance.

Massive lag typing upto 5 secs before chars appear.

Exactly the same versions now via direct access and its fine again.

Great app tough, I would be lost without it

And so can I!
Plus the characters/cursor jumps to the end of the note-page...
I don't know why or when it happens but i seem to be missing some characters afterwards, so it slows the flows..

I have to copy and paste and pay a lot of attention cause otherwise there will be nonsense typed which I cant understand after a week.
And i do need to b specific about decisions being made...

Update: 04-nov-2008
I changed my USB TR usage into 256MB.
It makes it better but the problem still exist. I am going to test with my PC version.
I still dont like to loose so much Ram to TR.
I still want to be able to work after planning what to Get Done...
more later....

When that happens, I just close TR and then open it again. It works well for some hours until the lag appears again.

It should be fixed of course, but not an important bug for me.