It is certainly possible that Komodo 5 is slower than Komodo 4 - I'd imagine that is only marginally slower though (I've not noticed any slowdown myself - though maybe I've just gotten used to it...).

There are a lot of new features in Komodo 5 - such as the editor history tracking feature and find highlighting - which will cause Komodo to use more CPU than Komodo 4, though we believe the trade-off has certainly been worth it (as far as performance goes).

After testing the "Ctrl+PgUP|Down" I do notice it's quite slower in my regular Komodo 5.1.x profile when compared Komodo 4.4.x, though if I use a totally fresh Komodo 5.1.x profile I do not notice any differences between the two (I have added a large amount of scripts and extensions to my regular Komodo 5.1.x profile which I'd imagine is what is slowing Komodo down).

Try testing with a completely clear profile, i.e. from a windows command prompt try this:

Cheers,
Todd

Hi Todd,

Thanks for the reply. I started Komodo in that configuration, closed the Start page tab, then opened to .pm files.

Ctrl+PageDown-ing through them shows in Process Monitor a lot of accesses to C:\komodoide\5.2\dandv\history.sqlite and C:\komodoide\5.2\dandv\history.sqlite-journal

I presume that's what's causing the hard disk to grind (I do have a noisy hard drive, which tipped me to this intensive disk access issue). Probably Komodo saves the tab state all the time so that it can restore the session exactly as it was in case of a crash? This feature indeed is not in Komodo 4.

Komodo has to do a bit more tracking than Firefox though.

Currently every time you jump to a new "section" (function,
module, etc.), switch files, or make a relatively large
jump via a function like brace-matching or go-to-definition,
Komodo records the old location, so it's easy to switch back
to it.

Obviously this convenience has a price. We've done benchmarks
for this feature all along, and dropped some features that
were determined to be too costly. I'll escalate our plans
to make the overall history feature configurable, and we'll
see if that improves the performance.

Regards,
Eric

I don't think that history in Komodo sessions need to be persisted. Keeping track of actions is very useful, but not from a session to session. Storing history in only memory is sufficient. No need to abuse our hard disks.

One of the goals of the history feature is to help people resume
a task after a break, like a weekend, a vacation, or time spent
on another project. We don't need to save all the information
for medium-term info that we do for the short-term, but a database
is the right choice.

As for an in-memory-store, I'm not sure if this is an option with
sqlite3, nor how much memory this would take up.

I also have a work item to make history fully optional.

- Eric

> One of the goals of the history feature is to help people resume
> a task after a break, like a weekend, a vacation, or time spent
> on another project. We don't need to save all the information
> for medium-term info that we do for the short-term,

I agree with that statement. In that case, it's not that important which tab was last open or which item in a search was the current one. Komodo 4, however, remembered editor tab order and edited file positions and didn't write to the disk all the time, which makes me doubt that:

> a database is the right choice.

Anyway, there's also the possibility that Komodo crashes. In that case, it's useful to persist sort-term context, and Komodo 4 doesn't do that.

> As for an in-memory-store, I'm not sure [...] how much memory this would take up.

If memory is a problem, how about having it store change instructions that get committed to db either every minute, when a read operation on the db is performed and when Komodo is closed?

SQLite is a nice database solution, but it is not meant for continuous high performance applications, so you will want to find a method to avoid writing to it unless absolutely necessary.