Performance with many open tabs

I connect to several databases and regularly open a lot of tabs (easily 100+) in a single session. After a certain threshold, HeidiSQL becomes very slow after running a query. Seems it loops over all the tabs, updating something, with flashes of "Executing query #2 of 1" and "Sorting grid nodes".

Anyway to avoid this behavior altogether? When reaching 50+ tabs or so, the wait for Heidi to become responsive is 10+ seconds and rapidly gets worse.

Probably my modifications in the latest build help a bit here - please update through About > Check for updates.

Apart from that, having large results open can indeed cost much CPU performance. Without a more exact analysis, I can only recommend to decrease the number of opened tabs to < 20.

I'll try an update over the weekend. I'm always hesitant to update during production hours - not all changes makes me instantly more productive :-)

As for results open, they usually "go away" simply showing "<node><node><node>" after a while anyway. Not sure what the "queries" are that are flashing by in the lower right corner, but it can't be re-running the SQL:s because that would be really slow and also I don't get refreshed data sets. It appears to simply be updating some kind of metadata.

I'm also rarely interested in the actual results in the tab - I just want to keep the queries. I can always refresh them if I need a new result set.

Restarting Heidi, waiting for it to load my 100 tabs is fine. Then running one query (with all the other tabs now being without a result set) still performs the same way. The query in the current tab runs, displays the results, and then the very long process of "updating something in the background" starts. Even though every tab now simply contains a restored query.

My point is that it doesn't appear to have anything to do with the actual result sets, but rather some kind of meta-data collecting, that would be better to do "on demand".

Oh, and failing a query, with a "unknown column name" or whatever, yields the exact result I want - straight back to the editor, nothing being updated etc. It's only after a successful query, however short, that updates the current tab's result pane, that the slow update run begins.

Just updated anyway, to make sure it hadn't gone away. Here's a movie showing how it works for me currently.

Running a query that takes ~5 seconds. Then there's 20+ seconds of "odd updates".

I think I will try myself. If you say having a result makes no difference that should be easy enough. I just guess 100 tabs will eat much of my available screen space :)

Nah, it's fine on 2560x1440 :-)

This thread prompted me to try an ugly hack, and sure enough, if I end my query with ";X", it will first render the result, then fail with a

SQL Error (1064): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'X' at line n

...and then leave all the other tabs alone.

Problem almost solved, but at least it might give you pointers in the right direction. I'm not keen on clicking away error boxes all day either, but it's faster than a 20 sec wait for "updates" :-)

Fixed in the next build. See attached gif animation.

Cause was an update to the "Query history" tree node in each tab's helpers panel on the right side. The logic was: query was executed, so I need to update the history. I modified this in a way that only the active tab's history is updated atfer a query, plus updating other tabs when they get the active one.

Thank you very much for this Ansgar, this change was a true life-saver for me!

I've installed the snapshot and can confirm that it works as described. History is retained between tabs (it seems at the expense of a very small and very tolerable update when you switch tabs instead).

The entire app just feels snappier. Moving between databases, connecting to new ones, opening views/tables/procedures, everything.

You just supercharged Heidi over the weekend!