Investigation: CodeMirror + New WikiText Editor performance issues
Closed, ResolvedPublic5 Story Points

Description

There is a hacked version of CodeMirror + New WikiText Editor here: https://gerrit.wikimedia.org/r/#/c/343878/

This version works by loading CodeMirror underneath the WikiText editor surface, making the text and background of the WikiText editor transparent, and syncing user input from the WikiText editor to the CodeMirror surface as it is entered.

One potential issues with this approach is: "Due to the fact that VE edit surface is not fixed height (its an auto-height textarea), we lose CodeMirror's viewport performance optimisation (https://github.com/codemirror/CodeMirror/issues/4076). It may be possible to have CM resize to the viewport height and then sync scrolling, but this itself may be slow and/or cause alignment issues with the VE surface. I've experimented with doing partial syncs as doing a full document setValue is unnecessarily expensive, but even with that, the loss of the viewport optimisation still makes typing feel a little sluggish."

Use the hack to investigate this issue and see if there is a way to improve the performance.

kaldari created this task.Mar 21 2017, 10:10 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 21 2017, 10:10 PM
kaldari set the point value for this task to 5.Mar 21 2017, 10:24 PM
DannyH triaged this task as Normal priority.Mar 21 2017, 10:33 PM
DannyH moved this task from Sprint planning/estimation to Backlog on the Community-Tech board.
kaldari updated the task description. (Show Details)May 3 2017, 5:39 PM
Dvorapa added a subscriber: Dvorapa.May 3 2017, 6:41 PM
DannyH raised the priority of this task from Normal to High.Jul 5 2017, 11:09 PM
Niharika claimed this task.Jul 12 2017, 9:49 PM
Niharika moved this task from Ready to In Development on the Community-Tech-Sprint board.

FWIW it seems fine to me (albeit on a chunky laptop). It's not as fast as it could be but it's trivial.

I haven't been able to find any problems yet either. Works fine with different viewport sizes.

TheDJ added a subscriber: TheDJ.EditedJul 13 2017, 8:56 AM

We should check the effects on older browsers and the worst laptop with throttled connection that we can find. I'm pretty sure the Obama article will become terrible at some point in that situation. This ticket should focus on how to make that 'terrible' experience as best as it can be. For instance by popping up a waiting spinner after half a second, or by automatically disabling syntax highlighting and popping up a notification bubble to state this...

But yes, performance so far is impressive.

Niharika added a comment.EditedJul 18 2017, 10:33 PM

I copied over the Obama article to testwiki for testing it: https://test.wikipedia.org/wiki/Test_page_long and used throttling (Chrome browser devtools) to limit my connection speed. I disabled caching for testing.
My test device, however, was a ~3-year old fairly powerful MacBook Pro. Here's an analysis of what I found:

SpeedEditorLoad time with CodeMirror disabled*Load time with CodeMirror enabled*Time taken to highlight after clicking icon
GPRS (~50kb/s)Classic with wikiEditor toolbar enabled51 seconds1 minuteInstantaneous
2G (Regular) (~250 kb/s)Classic with wikiEditor toolbar enabled12 seconds15 secondsInstantaneous
GPRS (~50kb/s)NWEErrored out after ~2 minutesNo point checking this¯\_(ツ)_/¯
2G (Regular) (~250 kb/s)NWE21 seconds35 seconds2 seconds

*I did each of these tests thrice and averaged them, roughly.

I can try the same with other browsers and maybe an older machine but I think these stats look decent.

To make sure we test against https://gerrit.wikimedia.org/r/#/c/363644/, let's retest against the NWE on 2G and a higher speed.

FYI on MacOS Apple has something called network link conditioner available, which also allows you to simulate dropped packets and dns latency.

My main concerns are not with load times, as they should be comparable to VE (slightly faster), but without the viewport optimisation every keystroke can trigger a full document re-rerender which makes typing sluggish on long articles (e.g. Obama).

Given Marijn's response on https://github.com/codemirror/CodeMirror/issues/4076 I don't think viewport optimisation is a realistic goal.

The only other solution I can see for performance would be to make the edit surface fixed height. This could be dynamically to match the height of the viewport so we don't have double scrollbars, or could just be a fixed value like WikiEditor.

My main concerns are not with load times, as they should be comparable to VE (slightly faster), but without the viewport optimisation every keystroke can trigger a full document re-rerender which makes typing sluggish on long articles (e.g. Obama).

I have tried the Obama article (https://test.wikipedia.org/wiki/Test_page_long) with NWE and haven't noticed any lag but I need to find a poorer device to test on than my MacBook. I'd like to make sure this is a problem first.

I love it that VE/NWE don't have a fixed size edit surface and wouldn't vote on changing that.

I did the same test with an older laptop (less RAM and weaker processor) and also didn't see any significant lag. The only time I noticed some lag was when I was scrolling the page rapidly but it wasn't too noticeable.

I'd say we wait until we get any reports about performance issues from users before investing time to fix this.

On a much more old Dell Thinkpad, it was noticeably slow at redrawing the page. It was fast initially but as I typed faster, it got slower and lag got more noticeable. It was about 1-2 seconds to render it. :(

Quick tests on our own devices are useful as a rough indicator. Can we also test this more comprehensively somehow? If this is put out there and users complain of performance issues, having a more rigorous study of performance would be beneficial.

Quick tests on our own devices are useful as a rough indicator. Can we also test this more comprehensively somehow? If this is put out there and users complain of performance issues, having a more rigorous study of performance would be beneficial.

@kaldari Can/should we summon TSG for doing this?

@kaldari Can/should we summon TSG for doing this?

That'd be great if we could! I've found their prices incredibly affordable compared to other options in the past.

DannyH added a subscriber: DannyH.Jul 25 2017, 7:08 PM

@Niharika: I'm not sure how we would have them reliably quantify the lag. Besides, the original point of this ticket was to explore how we might address the lag, not proving that the lag exists.

@Niharika: I'm not sure how we would have them reliably quantify the lag. Besides, the original point of this ticket was to explore how we might address the lag, not proving that the lag exists.

Well, if there were no lag in the first place, addressing it would be a foolish thing to do. :)

I personally don't think the lag is significant because I only noticed it when:

  1. The device was fairly old.
  2. The user had both NWE and CodeMirror beta features enabled.
  3. The page was very long (longer than the Barack Obama article).

So my conclusion from the investigation would be that we don't address the lag unless we know we hear complaints about it.

The only other solution I can see for performance would be to make the edit surface fixed height. This could be dynamically to match the height of the viewport so we don't have double scrollbars, or could just be a fixed value like WikiEditor.

The first solution sounds a bit hacky (but possibly doable) and the second solution sounds like it would be a slight downgrade of the user experience. Either way, they are both pretty drastic measures and would probably only be worth doing if there are significant complaints about the performance during beta testing.

I tried the (shorter) Pride and Prejudice article on NWE with syntax highlighting on and off, and even on my MacBook on a shorter page, typing is laggy with NWE + CodeMirror.

Loading the page is basically the same -- it takes a while to get to NWE whether it's got CodeMirror on or not.

But typing my usual typing speed, there's a noticeable delay. If that was my experience, I would either turn off NWE or CodeMirror.

@Esanders: Am I correct in assuming that neither of your proposed solutions in T161054#3461460 would be possible to implement quickly? If not, we may want to consider launching CodeMirror without NWE support initially, until we've come up with a good solution for the typing lag. Any thoughts on that?

I'm not 100% sure but I think providing codemirror the viewport dimensions wouldn't be hard. We need to pass them as part of the initial config options.

@Niharika: Yeah, I think that part would be easy, but I imagine converting NWE to fixed height would involve some complicated hackery to NWE. @Esanders: Thoughts?

@Niharika: Yeah, I think that part would be easy, but I imagine converting NWE to fixed height would involve some complicated hackery to NWE. @Esanders: Thoughts?

Why do we need fixed height for NWE? What I'm proposing is, when CM launches, whatever the screen dimensions, we pass them to CodeMirror and it draws that area. The editor height doesn't have to be fixed then. Does that make sense? I'm not sure it'll work.

@Niharika: But then what happens when the user scrolls? If the CodeMirror div only covers the part of the NWE that is in the viewport, it won't work very well when the user scrolls down.

@Niharika: But then what happens when the user scrolls? If the CodeMirror div only covers the part of the NWE that is in the viewport, it won't work very well when the user scrolls down.

I said "dimensions". The size of the viewport. On scrolling, the new area gets drawn. I think that is what currently happens in the classic editor.

@Niharika: I don't understand what you're suggesting. Right now the NWE is the size of the entire article. If CodeMirror covers the entire NWE, it will highlight all of the WikiText (and be slow). If CodeMirror doesn't cover the entire NWE (for example only covering the initial viewport), it will scroll out of view when the user scrolls the page. In order for that to work, in seems like we would have to do some really complicated hackery to make the CodeMirror div slide down the page as the user scrolls the page.

kaldari closed this task as Resolved.Aug 24 2017, 8:32 PM

OK, I think this investigation has accomplished all it's going to accomplish for now. We've established that there is a performance issue, mainly around typing delay. The issue is most prominent on large articles on slower machines. None of the proposed solutions are easy to implement, so we're going to take a wait and see approach, i.e. wait and see if this issue is a significant enough issue for users to warrant further work.

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptAug 24 2017, 8:32 PM
DannyH moved this task from Backlog to Archive on the Community-Tech board.Aug 31 2017, 12:35 AM