Riot is unable to start correctly most times

[turt2live]

Description

For the last few days I've been getting the prompt from Chrome to kill the tab repeatedly when refreshing/starting Riot. When looking at my CPU usage it's clear that Riot is stuck doing something, although my environment is refusing to let me profile it for whatever reason.

I've yet to come into a case where pressing "wait" instead of "kill page" actually gets Riot to load. I've had to kill the page and try again every time (usually it starts fine on the second or third attempt to open Riot).

The visible failure mode is that I'm able to see the spinner move (which makes sense - it's a gif), however I cannot interact with the page at all, open dev tools, etc.

Suggestions on how to actually profile this to get useful information would be appreciated.

Version information

• Platform: web (in-browser)
• Browser: Chrome 64
• OS: Windows 10
• URL: riot.im/develop

[lukebarnard1]

@turt2live has this improved recently?

[turt2live]

@lukebarnard1 I see the prompt about 50% of the time when starting Riot for the first time in the morning, but otherwise it has decreased it's frequency significantly.

[ara4n]

can you start a perf profile going the second you open it?

[turt2live]

This is now #6060 for me - closing as the root issue described here is fixed.

[turt2live]

Re-opening: I still get this when doing a sync for the first time in 1+ days (in my case, 3 days).

Not so long ago (January?) this kind of gap in time would cause things to slow down, but not so bad that Chrome wanted to kill the tab. In this case it is clearly related to some sort of Riot thing because the /sync request returns within a couple seconds, despite being a few days old.

I got a profile, but it doesn't actually reveal much (besides it stopped working and sat idle for over a minute). I've sent this profile to you directly @ara4n

[lampholder]

Adding to 0.14 just to force the conversation about what needs to happen with this.

[turt2live]

of course, since I've last complained the issue seemingly resolved itself (at least for the behaviour described in the OP). The remaining performance issues seem to be #6212 and #3307 now.