search

jakob / Postico

Public issue tracking for Postico
https://eggerapps.at/postico/
476 stars 9 forks source link

perfomance degradation for large view definitions #416

Open qwesda opened 7 years ago

qwesda commented 7 years ago

There seems to be something going wrong with the structure view for views with large/complex queries.

Viewing the structure of information_schema.routines vs information_schema.sequences i a good example. routines is noticeably slow compared to sequences on my machine (2016 15'' MacBook Pro).

jakob commented 7 years ago

I think this is actually related to the number of columns (see #6). I think that the problem isn't as bad as it used to be, because autolayout performance has improved significantly in recent releases of macOS. But to really fix this performance problem I will probably need to move away from autolayout for the structure view (or at least not use it as naively as I am currently using it).

qwesda commented 7 years ago

Yes, the column count seems to be the culprit. I had similar performance hits with CREATE TABLE routines_table AS SELECT * FROM information_schema.routines; and CREATE VIEW routines_table AS SELECT * FROM information_schema.routines;.

Do you have an idea why this is happening? Is something constantly invalidating the layout constrains?

jakob commented 7 years ago

The views have a lot of layout constraints (each line describing a column has a dozen constraints or so). Showing a view with many constraints is slow. (When the structure view is inserted into the hierarchy, Appkit needs to update the matrix of the constraint solver, which is very expensive when there are many connected constraints)

The solution would be to use something like NSTableView (like the contents view), where only visible views are actually added to the view hierarchy. This puts some limitations on the types of layout that are possible, but it would be much, much faster.

macOS 10.13 has improved support for autolayout in NSTableView (dynamic row heights!), so maybe I could use that. Not sure what to do about backward compatibility though....

qwesda commented 7 years ago

My question wasn't about the initial delay when opening the table - I didn't write that anywhere though ... But the UI continues to be less responsive after the view is loaded (and the constraints should be stable). Things like clicking inside the columns name textbox has noticeable delay without any obvious need for constraint re-evaluation.

I just thought maybe there is some low hanging fruit there - like some components that trigger an unnecessary constraint re-evaluation.

On the other hand this is not really a super terrible bug - you can probably leave it like this for a while.

jakob commented 7 years ago

Oh, now I see! I thought you were talking about the initial delay. I'll have a look what's going on.