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.

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.

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:

*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.

In T161054#3460213, @Esanders wrote:

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.

In T161054#3465427, @Deskana wrote:

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?

In T161054#3465620, @Niharika wrote:

@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.

@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.

In T161054#3475987, @kaldari wrote:

@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?

In T161054#3494090, @kaldari wrote:

@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.

In T161054#3529652, @kaldari wrote:

@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.