[solved] Tracy Console almost unusably slow

[bernhard]

I'm on a Macbook Air M1 and whenever I'm using the Tracy Console things get extremely laggy. Sometimes even several keystrokes take seconds which is obviously really a pain. I'm wondering if I'm the only one experiencing this behaviour?

Does anyone know how that can happen or how that can be debugged?

[adrian]

No issues here on M1 Macbook Pro. I don't really know how to suggest debugging, but is it all sites or just local dev ones? Stupid suggestion probably, but does a machine reboot help? Is this a new issue, or has it always happened on this machine?

[bernhard]

Thx for your answer! Don't think that a machine reboot helps. The issue has been there for a while. Not sure what's going on. It's really hard to tell or identify. I'll try to record it when it happens again.

Just wanted to make sure I'm not missing anything obvious and maybe someone else has also experienced this?

[gornycreative]

I thought I was the only one. Keyboard lag is brutal with the latest chrome. I figured it was chrome's new inbuilt 'privacy protection' spy features.

[gornycreative]

Here's my panel list - maybe we've got a common panel causing realtime lag?

Are you using UserActivity?

[adrian]

I just tested on the latest version of Chrome and no problem here. Not dismissing this as an issue - just trying to help rule things out.

[bernhard]

Just kidding ? 

Maybe it's one of my modules if @gornycreative is also using them and also seeing the issue?! Maybe we can track it down further. Can you check if it only appears with RockFrontend or RockMigrations for example? I always have both installed, so I can't test ? 

Good to hear that I'm not the only one seeing this. Maybe others can also report their observations and we can put all pieces together and find something.

PS: I'm also on Chrome.

[netcarver]

I don't know what's going on - so just throwing an idea into the ring. Could you try looking at your wire cookie id and then checking the size of the session associated with that same id?  If it's extremely large, could you try deleting the file (or row in the DB session table) - which will log you out when you reload the page. When you log back in, is tracy any faster?

[bernhard]

Thx for the input @netcarver I don't think that it can have anything to do with anything on the backend. PW itself is fast, I'm just experiencing a very laggy console on the frontend. Sometimes even the mac os spinner pops up for some seconds. Do you think that can have anything to do with sessions or cookies?

I'm thinking maybe the SSE stream of RockFrontend/RockMigrations livereload could interfere somehow? Just throwing in an idea as well ?

[netcarver]

Yeah, it's probably not this - just wanted to rule it out as a possibility. I think your guest session on the front end will still have a session file unless you set up the config file to prevent it. If you do a ls -lSh site/assets/sessions/ and the guest session id is relatively large, then something is stashing a lot of data in there. Unlikely though.

[BrendonKoz]

Oh, specifically for the console. I believe I experienced this once as well. Will try to be more attentive. Hasn't happened since. I am not using any Rock modules currently, though since it's only happened once to me I would lean more toward PC performance over module in my instance.

Have you tried a different browser just to see if it's primarily a Chrome (on Mac?) thing? Safari / Firefox... If you have access to a Windows or ChromeOS box, maybe try Chrome there too?

Chrome has a task manager. When you notice the issue - assuming you've reduced your Chrome tabs to just the one (?), does the task manager give any additional insight?

Similarly, Chrome's DevTools offers a runtime performance monitor (not the same thing as is shown in the above photo)... Just some things to look into.

[bernhard]

Thx guys that helps a lot and I'll try to check your suggestions when I experience the issue for the next time!

[cwsoft]

16 hours ago, bernhard said:

I'm on a Macbook Air M1 and whenever I'm using the Tracy Console things get extremely laggy. Sometimes even several keystrokes take seconds which is obviously really a pain. I'm wondering if I'm the only one experiencing this behaviour?

Does anyone know how that can happen or how that can be debugged?

Have you tried with a clean default PW installation with a default template and just Tracy installed? If that works try to install your two rock modules in two steps and check if console lags still occur. Thats what I would try to narrow down the possible error sources. If you can find a reproducible setup it‘s easier to spot the error for others like Adrian too.  

[gornycreative]

Testing in the latest Firefox on windows 10, I get no lag at all.

Although I do get a weird cursor line flicker - not sure that is normal - that follows from the top left of the window corresponding to the cursor editing area in the panel.

I'm guessing there is a bit of memory/interference being caused by the new security features in chromium-based browsers. This include at least Chrome and Brave browser - haven't tried Bing yet.

[MarkE]

I have had this problem sometimes on a windows machine. It seems to happen for no apparent reason and then go away again. I know that’s not very helpful. Intermittent bugs are the hardest to track down. However, it is helpful to know you are not alone! Next time it happens, I’ll pay more attention to what might have caused it. 

[bernhard]

Hey @adrian I'm still having this issue. Can I somehow disable the autocomplete feature of the ACE editor? That would be my first guess and it's really not useful to me anyhow. I tried to find it in the code but didn't ? 

[adrian]

Tracy module settings > Code Editor Settings:

[bernhard]

I've even had a look at the module settings!! Didn't spot it there as well - thx a lot ? We'll see if that makes a noticeable difference.

[bernhard]

I think I found the issue! The issue occurs if you dump a large dataset!

I had some code to test the performance of a $pages->find("something") call... For that I first loaded all pages via $all = $pages->find("include=all") and dumped it via db($all) which showed the following:

This was enough to make the whole page really laggy. Even when hovering the debug bar it took quite long for the pop-ups to appear. After a reload everything was snappy, so the issue occurred only after I executed the console code at least once.

Seems that the dump adds so many elements to the dom that the browser can't really handle it!

Not sure what we could do about this? I'm using default values for dumping:

[adrian]

That is the reason that d() is the standard method for dumping rather than db (dumpBig). d() uses those defaults, but db() overrides them.

[bernhard]

Yeah, just wanted to edit my post to state that I might need to change my habits here ? I'm always using db because it's annoying to not get the full result. Didn't realise that it has that side effect.

Awesome. All the settings to fix this issue are already there ? Limiting the number to 20 and nesting to 3 for example makes everything stay snappy. Great!

Thx for your quick help.

[adrian]

Yeah, PW page objects are pretty huge. I wonder if you might also benefit from removing the Full Object tab from the dump and just going with the Debug Info tab? Personally I wouldn't because there are times I do want to look through the full object, but perhaps you might find it a better option?

[bernhard]

6 minutes ago, adrian said:

Yeah, PW page objects are pretty huge. I wonder if you might also benefit from removing the Full Object tab from the dump and just going with the Debug Info tab? Personally I wouldn't because there are times I do want to look through the full object, but perhaps you might find it a better option?

Yeah I'm indeed not using that often, but once in a while it comes in handy.

What about adding a warning to db() and bdb() calls?

This is the markup I used:

<svg title="Warning: Dumping large objects might slow down your browser! Use d() or bd() instead." uk-tooltip style="color: orange; margin-right: 5px;" xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24" aria-expanded="false" tabindex="0"><g fill="none" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"><path d="M0 0h24v24H0z"></path><path fill="currentColor" d="M11.99 1.968c1.023 0 1.97.521 2.512 1.359l.103.172l7.1 12.25l.062.126a3 3 0 0 1-2.568 4.117L19 20H5l-.049-.003l-.112.002a3 3 0 0 1-2.268-1.226l-.109-.16a3 3 0 0 1-.32-2.545l.072-.194l.06-.125L9.366 3.516a3 3 0 0 1 2.625-1.548zM12.01 14l-.127.007a1 1 0 0 0 0 1.986L12 16l.127-.007a1 1 0 0 0 0-1.986L12.01 14zM12 8a1 1 0 0 0-.993.883L11 9v2l.007.117a1 1 0 0 0 1.986 0L13 11V9l-.007-.117A1 1 0 0 0 12 8z"></path></g></svg>

It might help others as well that are not aware of this issue.