It is known that Parsoid's raw performance for a wt->html transformation will not be as good as core's performance simply because Parsoid does more work. While we should and can continue to improve Parsoid's raw performance, that is unlikely to get us raw performance parity.
There are two options available to us:
- some form of incremental parsing solution (limited to say section edits, for example) that is enabled by Parsoid's approach
- throw hardware at the problem since it is not a performance goal to match Parsoid performance with core parser performance on equivalent hardware
This phab task is about exploring strategy 2. To get a realistic sense of what is feasible, @Sbailey noted in a recent team meeting that we probably need to get our hands on a test server. I tried to figure out if @tstarling had some readymade insights based on his recent performance work on Parsoid and turns out he doesn't.
So, this is a tracking task to:
(2a) check with serviceops to see what our options are wrt acquiring a test server
(2b) benchmark Parsoid wt2html on current production hardware and on the test server to get a sense of what kind of benefits we can get.