sequelpro

sequelpro copied to clipboard

I've got a query editor with about 100 lines of SQL in it. If I'm typing at the end of that sql - on line 100 - I get a normal response time to key strokes. If I move the cursor to line 1 and try typing there the typing goes at about 1 character per second. More lines = slower performance at the top of the file and it gradually improves as I move down the file. It makes the query editor very hard to use.

I've tried clearing the history, reinstalled Sequel Pro, restarted the computer, turned off all the query editor settings in preferences and none of that makes a difference.

I'm using a 2 week old MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) running Sierra. I migrated to this from an early 2015 MacBookPro running El Capitan and that did not have a problem.

Any suggestions would be greatly appreciated, thanks

as an update - when using the query editor Sequel Pro is hitting 99.9% of CPU and the mono-sgen process goes to > 100%.

Similarly I loaded a 1000 line file and scrolling around it becomes very jerky and unusable - again it depends on cursor placement. If the cursor is at the bottom of the editor it's fine, if it's at the top it's very bad.

I've found a partial solution to this. Performance of the query editor can be greatly improved by switching the font from Monaco to Menlo. It's still a little laggy at times, but it's much better

I also noticed that this is a duplicate of issue 2621 https://github.com/sequelpro/sequelpro/issues/2621

Well, you said you didn't have the problem under 10.11 and the poster in #2621 says he had the issue on both, 10.11 and 10.12.

True. There does seem to be more to it though than the OS version. I've tried it on 3 machines in our office: late 2016 Macbook Pro running Sierra : problem early 2015 Macbook Pro running El Capitan: no problem early 2015 Macbook Pro running Sierra: no problem mid 2011 iMac running Sierra: no problem

On the machine with a problem, can you create a new user account and try it with that?

Done - the new user account exhibits the same problem.

Experiencing the same behavior. MacOS 10.12.5, 15in 2016 MBPr, 2.6GHz i7, 16gb ram. Sequel Pro v1.1.2 build 4541.

Editor with ~200 lines. If I try typing on line 1, theres a 1 second delay between keystrokes, but typing at the end of the editor has almost no delay.

Idle CPU usage: ~5% typing at beginning: ~95-99% typing at end: ~10-20%

memory usages hovers around 250-350MB in all scenarios.

Have you tried what was mentioned above?

Performance of the query editor can be greatly improved by switching the font from Monaco to Menlo.

250-350 MiB is quite a lot of memory. Did you have > 10 connections open at that time? Also, possibly, you have a rather large query in your query history; try clearing that.

You can try to put Sequel Pro and Activity Monitor side by side, select SP in Activity Monitor and press alt+cmd+S (Sample process) and immediately switch to Sequel Pro and start typing where it is supposed to be slow (until sampling ends). Afterwards post the results of sampling.

I've attached a sample as requested. I note that my SP was running at 440Mb with 4 connections open and 550Mb+ with 6 connections.

Sequel_Pro_sampling.txt

Thanks, this sample shows one very interesting thing I hadn't thought about before: You are using a touchbar Mac and a significant amount of time in the sample goes to touchbar stuff.

But, since I don't have that fancy stuff I won't likely be able to reproduce it.

The irony for me is that I almost always use the laptop in Clamshell mode so I don't even have access to the touchbar.

I just tried https://red-sweater.com/touche/ and with that I'm also able to reproduce the issue.

It seems there are other people also affected by this: http://support.hogbaysoftware.com/t/laggy-ui-on-macbook-pro-15-inch-2016/2809/13 - I wonder what they changed.

Some quick testing shows that the expensive -[NSLayoutManager(NSPrivate) _fillLayoutHoleForCharacterRange:desiredNumberOfLines:isSoft:] method is usually called once for each character typed, but in Sequel Pro (on Sierra) it is called 65 times for a single character.

Interesting. Thanks for digging into it.

I moved the SPTextView class to a simple test app and debugging showed that the NSMutableAttributedStringAddAttributeValueRange() calls in -[SPTextView doSyntaxHighlighting are what is triggering the slowness.

But...for some very odd reason when disabling "Uses: Font Panel" in Interface Builder, it starts working fine again.

This seems to be caused by -[NSTextView rangesForUserCharacterAttributeChange] which is called internally by macOS and which is documented as:

For plain text the range is the entire contents of the receiver. Returns nil if the receiver isn’t editable or doesn’t use the Font panel.

Apple then uses that range to call -[NSAttributedString enumerateAttributesInRange:options:usingBlock:] which invokes block each time the style attributes change (e.g. 400 times in a 2100 character SQL string) and ends up calling -[NSFontManager convertFont:toHaveTrait:] each time (which is extremely expensive for some fonts, e.g. Monaco, while working fine for others, e.g. Menlo).

I still don't know what Apple is trying to achieve here regarding the touch bar, but it seems like they forgot that a plain text NSTextView can still have different text styles applied.

Does that mean that it requires Apple to make fix before this will work properly?

IMHO yes, but if I were to file a bug with them about this it would usually take 6-24 months for their initial response and another 10 months to fix it (should they decide to feel responsible and are not already aware of it). Talking to Apple is pretty much a dead end unless you pay them some hundred dollars for per-incident support and even then there is no guarantee that they can actually help with the issue...

So basically we have to think about a different solution. For the moment you should change the font of the query editor to Menlo as that seems to cause less problems.

Another option may be to disable Touch Bar for Sequel Pro by going to System Prefs > Keyboard > Shortcuts > Function Keys and adding Sequel Pro there.

FWIW, switching the touch bar to always show function keys for Sequel Pro didn't seem to make a difference for me. Switching to Menlo does seem to help a little, but not completely.

The symptoms I'm experiencing are pretty much the same as the OP - if a lot of text is in the editor window, it's extremely responsive when typing at the bottom of the editor window, and gets less responsive the further up the content I scroll.

+1 on this issue. Switching to Menlo helps a bit, disabling touchbar does not help at all.

+1 as well. Just got the new macbook pro with touchbar, and the query editer is now unusable 😔. Anyone have any other potential work-arounds for this?

+1 here... Thanks for digging in to this and finding at least partial solutions (Menlo).

+1 on this. Switching to Menlo does help a bit, but not much.

on Mojave, even switching to menlo now has no impact 😔

+1 on this changing the font to menlo improved a bit, but slowness is huge

I disable all the "helpful" options in the Query Editor preferences pane. "Highlight current query" in particular really slows things down for me and adds nothing of value. Now things are pretty snappy even with several hundred lines.

We really need the ability to disable syntax highlighting as well, that should speed things up a lot.

+1 just got a touchbar and I use Query Editor all day. This is killing me.

Same issue on 10.13.6 MacBookPro15,1 (touchbar) Once the query editor reaches ~100 lines, the slowness begins. Switching fonts improved it.

Same issue on 2018 MacBook Pro 15" with Touchbar on Mojave.

Switching to Menlo helps a bit but again not much.

+1 Very frustratin, no touchbar here, same experience, changinf the font helps but it's minor

I can confirm that turning off all typing assistance preferences for the query window and switching to Menlo has greatly improved performance. Never really needed those preferences anyway, so I'm happy for now.

I'm on a 2018 Macbook with touchbar Mojave