964091 - UI refresh regresses rendering performance

Status: RESOLVED FIXED

(Webtools Graveyard :: DXR, defect, P2)

Description

[Nick Cameron [:nrc]]

The UI refresh uses one big table for an indexed file's page, whereas before DXR used many divs. I worry that using an enormous table will lead to performance regressions (especially on large pages).

I measured browser.js (~7000 lines, so big, but not enormous by Firefox standards) in the Gecko profiler on the two branches and found that the rendering time was 4s on the UI branch and 2s on master (i.e., 100% slower). This was not a scientific test in any way so I might be dead wrong, but I think it needs more investigation.

If it is an issue, I'm sure layout people would be happy to advise on how to to optimise, I would recommend pinging one of dbaron, roc, or dholbert.

Comment 1

[Erik Rose [:erik][:erikrose]]

If you really want a testcase, try http://dxr.mozilla.org/mozilla-central/source/db/sqlite3/src/sqlite3.c. Unusable on the ui branch. Practically brings down my browser. Works chunkily but usably on master.

Comment 2

[Schalk Neethling [:espressive]]

(In reply to Erik Rose [:erik][:erikrose] from comment #1)
> If you really want a testcase, try
> http://dxr.mozilla.org/mozilla-central/source/db/sqlite3/src/sqlite3.c.
> Unusable on the ui branch. Practically brings down my browser. Works
> chunkily but usably on master.

Is there any way we can grab like a subset of moz-central that includes bits like the above for local testing?

Comment 3

[Erik Rose [:erik][:erikrose]]

I think sqlite3.c is design to be pretty dependency-free; that's its whole point. You could probably whip up a trivial makefile for just it. Better, just make a 100,000-line Python file. That'll have just as many colored regions as a C one and should perform the same.

Comment 4

[Schalk Neethling [:espressive]]

So, I have gabbed the sqlite3 source and built it with dxr and now have a couple of files with around 25000 lines of code and I can see the browser starting to stutter. I am going to do some testing to figure out what is causing the slow down however, one thing I am wondering about is, whether the loading of the nunjucks templates could be contributing to this.

In production they should be precompiled as described here:
http://jlongster.github.io/nunjucks/api.html#precompiling

I will also give this a whirl locally.

Comment 5

[Schalk Neethling [:espressive]]

Attachment: Screen Shot 2014-01-30 at 23.31.08.png

Looking at the Profiler's feedback in Fx and Chrome, it definitely seems that loading those templates every time, instead of having the precompiled templates, is having a big effect on initial load and performance.

I will get the procompilation working locally first thing in the morning and see whether this 'assumption' is correct.

Comment 6

[Erik Rose [:erik][:erikrose]]

It's not just page load time that killed me. It's scrolling speed. There aren't any templates being loaded while you scroll. And I see only 4 nunjucks templates get loaded on a file page, so I'd be surprised if that makes a difference beyond about a second.

Comment 7

[Schalk Neethling [:espressive]]

(In reply to Erik Rose [:erik][:erikrose] from comment #6)
> It's not just page load time that killed me. It's scrolling speed. There
> aren't any templates being loaded while you scroll. And I see only 4
> nunjucks templates get loaded on a file page, so I'd be surprised if that
> makes a difference beyond about a second.

Indeed, and I have a pretty good idea on improving that as well.

Comment 8

[[github robot]]

Commit pushed to ui at https://github.com/mozilla/dxr

https://github.com/mozilla/dxr/commit/5318f8382163e94f4d951d65aa48190f0ea23ac4
Fix Bug 964091, precompile nunjucks templates always, remove pointers bit as it is strangely having the opposite effect