[yurkennis]

I am huge fan and heavy user of Bonsai. So huge and so heavy that the main outline I work with day-to-day is 2500 items, 1MB in size--and another outline I deal with during every weekly review counts 5000 items and is another 2MB in size.

The problem side of this huge success of Bonsai is that it is way too slow at my Treo 680 (the fastest PalmOS smartphone money can buy?).

Here are some examples of how slow it is with outlines of sizes like above (all with my default filter applied: "Incomplete only; no other criteria"):
- open outline which is zoomed in at a small branch: 20 sec
- Zoom Off to level 1, collapsed: 13 sec
- save current outline when I open another outline: 10sec
- add new item: 17sec

Tap-and-move a branch from one place to another in the same outline: proportional to branch size; several minutes is typical for large branches.

All these led me to migrate from 3-month to 1-week horizon in planning (before that, I dealt with 7000 items which the above timings mostly refer to), but things didn't improve enough. Adding new items is still very painful, and I have to use desktop-side application even on the road--instead of Palm-side Bonsai.

Is it possible to seriously improve performance of Palm-side Bonsai?

[slwenglish]

Wow! My largest outline is just over 1500 items & 628kB, with lots of notes for each item. Running on a T3, everything runs as fast as I can think (which probably isn't saying much ;-). So, the slow down happens somewhere between 1500 and 2500 items.

You must be using Bonsai for keeping a record of activities, like me. Have you thought about archiving checked-off items to Daynotez? Alternatively, you could save archive copies of your outlines, then carry on with a working copy with all completed items deleted?

Stéph

[yurkennis]

Yes, there are some notes--but it doesn't affect number of items, only size of outline.
No, I do archive most of completed items every 3 months.

The issue is about large projects (or themes that split down to individual projects) that last for more than a year.
Starting over from a new outline helps for half a year or so, but that's not a good lifetime I think--and after all, why write down anything if it very likely won't survive a half-year horizon?

And--TT3 is much faster than Treo680 (used to live with both); reason for sticking to Treo is one gadget in my pockets instead of two. If nothing else help, will consider migrating back to TT3--but I won't be happy if it's the only scenario.

[Richard Murphy]

I am a little surprised that Bonsai for Palm would be having such a problem. I wonder if it is related to the Treo's NVFS filesystem and the fact that Bonsai is attempting to access a large outline database. It could also be related to accessing your PIM database if you have Calendar or To Do links. If you are willing to send me your outline, I can forward it to the palm developer and see if he has any comments. Given the current state of the Palm OS market, it is unlikely we would put much time into this if it was not an easy fix. I would also be interested in testing your outline with our Bonsai for Windows Mobile product to see how it performs. If willing, please email to support [at] natara.com.

[yurkennis]

I don't have any links to ToDo or Calendar (literally one or two for the whole outline).

Of course, Treo memory is somewhat slower than TT3's (as it's non-volatile in Treo), but even simple observations show that many delays can be reduced merely by optimizing the software (I can provide more details if it can help).

Do you think Windows-based version will be much faster? I think you can reproduce the issue on Palm with any artificially created large outline, but I have just sent a real-life sample desktop-side outline for you.

I think there are two most annoying things that, when fixed, will improve the whole experience significantly:
= moving large branches up and down, promoting and demoting (if any single move of a large branch will modify only a parent node, but not all the many [grand] childs it may have)
= adding new items and deleting items
= editing notes for an existing item
Those are most frequent operations that, while are slow, kill the interactivity of application entirely.

[cleve]

I have an outline in the 1MB range with over 5000 items. I have never had any speed issues, but the outline frequently gets "lost". I think NVFS is the problem, so I just back up like crazy. It happened again this morning.

[cleve]

Does your outline reside in main memory or on the card?
If I store on the card, things get really slow.

[yurkennis]

Cleve,
Outline is in memory, of course. You are right that having it on a memory card slows down even more.
What device are your using with 5k-items outline? Do you have any filter applied most of the time? Are you working with most branches collapsed or expanded most of the time? Any other ideas why it's fast enough in your case?

[Tzalmaves]

My outline has 4576 items in it and, like the OP, Bonzai is so slow that's it's unusable on my Treo 680. When I check off an item, it takes 15 seconds or so for the list to update. It's really bad.

It was a bummer to purchase a desktop/PDA solution and discover that de facto it's a desktop-only solution.

The outline is not on a memory card, and I have not more than 6 or so links to calendar or todo items.

For a list of this size, it's hard to understand why it's so slow if the database is implemented sensibly (linked-list, efficient search algorithms, etc.)

-TM

[Richard Murphy]

I received your outline and have briefly tested on a T3 (non-NVFS). So far, performance has been good and have not seen any delays like you reported so that maybe an indication that the issue is indeed related to devices with NVFS. I will forward this on to the Palm developer and see what he thinks. I also tried it with the Windows Mobile beta version and found performance is slow, but that is not surprising since this is an early beta and has not been performance tuned. Overall, I expect the Windows Mobile version to be a bit slower than the Palm version. One of the major factors is the Windows Mobile version has a scroll bar for the outline grid. This requires the software to calculate the scroll bar range and position of the outline window. Since the Palm only has scroll buttons, it does not need to calculate this.

[yurkennis]

I've emailed an update detailing which filters demonstrate the performance problems.
Please let me know if it helps.

[yurkennis]

Quote

---

Originally posted by: yurkenniseven simple observations show that many delays can be reduced merely by optimizing the software (I can provide more details if it can help).

---

I have several observations that look helpful for this thread, although they are not killers for the "three most annoying things" I mentioned above. All timings refer to ".dtailsWFuture" filter turned on.

1. While return to current outline after editing notes for an item (with Notes command) takes 14sec after OK and 12sec after Cancel, doing the same with Notes tab of Details works immediately (wow!)
2. While adding a new item on level1 takes 17sec, removing an item takes only 4sec.
3. ZoomIn into a top level of a large branch (560 items) takes 4sec when it's part of a huge outline (2600 items), while it's only 1sec in an outline that has nothing except that branch
4. While scrolling from bottom to top works with all branches collapsed work really fast, tap-and-drag a bottom-of-1st-level branch to top slows down for a few seconds on every large branch I drag through (and the outline scrolls while dragging).

Is it possible to start with fixing these pieces if they are really easy?

[yurkennis]

BUMP, please.

[Richard Murphy]

The palm developer reported that inserts required about 3 seconds when not-filtered, and 5 seconds when filtered on a Treo 650 device (NVFS device). Not sure what would be different between the 650 and 680 devices. Have you tried doing a warm reset (so no background apps are loaded) and tried your test again? Does anyone else see unusual delays on the 680?
Generally we use an emulator for testing device specific issues but that is not ideal for performance type issues such as this.

[yurkennis]

Richard Murphy, on Aug 5 2008, 09:44 PM, said:

The palm developer reported that inserts required about 3 seconds when not-filtered, and 5 seconds when filtered on a Treo 650 device (NVFS device). Not sure what would be different between the 650 and 680 devices. Have you tried doing a warm reset (so no background apps are loaded) and tried your test again? Does anyone else see unusual delays on the 680?
Generally we use an emulator for testing device specific issues but that is not ideal for performance type issues such as this.

Treo650 is a bit faster than 680, but not dramatically in my experience with Bonsai on both: maybe 20% or 30% faster.

Just tried Treo680 with the outline I've sent to Natara, filter turned on: it's 8 sec for level1-item inserted on to the top of outline, and 6sec for level1-item added to the bottom. This outline is only 3800 items, 780kB. For another outline which is 4120 items, 1570kB, timings are: 10sec, 8sec. I can try the same measurements with an outline containing both week-horizon and 3month-horizon items, it will total in ~8600 items, 3000kB (which I would normally work with if Bonsai worked really fast)--the original "17sec" estimate referred to that outline. Does it make sense?

As for other users reporting delays: Tzalmaves above reported 15sec per each MarkAsComplete (with "re-apply filter while editing" setting turned on, I suppose).

So does your reply mean that you consider such delays for EACH insert as acceptable?
And what about other operations I mentioned above?

[Richard Murphy]

So you know, I asked George (our palm developer) to reply to your message. He has looked at the lost note changes issue but I guess he has not had time to reply to the thread.

[yurkennis]

So would you recommend to wait for another couple of days?

[George]

I think the unusual delays are when the Palm OS moves the outline records from the faster cache to NVFS. Differences between like devices would be caused by the amount of available cache that can be affected by other loaded programs.

The difference in your #1 item below is that the Details is a modal dialog displayed over the outline, whereas the Notes view is equivalent to the outline in being a 'View'. When switching back to the outline the view must be fully reinitialized.

[yurkennis]

So will there any improvements in performance implemented in the Palm version in the foreseeable future?

[Tzalmaves]

Is anybody home? A basic restructuring of your data structures should fix this problem. Please see my comments above regarding linked lists, etc.

Seriously, any first-year CS student should be able to re-write your data representation so that these delays go away. For example, when manipulating the list, only iterate over your data until you've filled the screen.

Will any effort be made to fix this? If not, please let me know so I can look for another vendor.

Thanks,

-TM