Parsoid in PHP, or There and Back Again • Hacker News Board

Re: Parsoid in PHP, or There and Back Again

#71

Post by kmaher » Fri, Feb 14, 2020, 10:27 PM UTC

lolphp111 wrote: post #69

Piskvorrr wrote: post #68

Earlier quoted context omitted.

"For me PHP sits in the middle as a poor language, and still slow compared to any compiled languages." No assumptions whatsoever. 2020: mobile clients. Yes, they're where the rest of the web was in 2005. Yes, they're ubiquitous.

I cant believe users on legacy phones (phones from say 2010-ish era) would be writing new content on wikipedia actively. I dont care if you have the newest iphone, you still dont write anything, you just read. For those 0.00001% of users who actually create new content they most def are not using a phone to do this. > "For me PHP sits in the middle as a poor language, and still slow compared to any compiled languages…

Not exactly accurate regarding mobile editing. Edits on mobile-heavy wikis are up 18% YoY, which we attribute to improvements in the mobile editing interface. We have people who edit on T9 interfaces. Not many, but they exist.

Re: Parsoid in PHP, or There and Back Again

#72

Post by znpy » Sun, Feb 16, 2020, 12:21 AM UTC

cscottnet wrote: post #64

znpy wrote: post #29

Last time i tried getting mediawiki up and running as a personal wiki i found out that getting parsoid working was quite a mess. hopefully now it will be easier to get a fully fledged wikimedia installation, together with a visual editor.

Yes. We're not there yet, but that's the goal!

awesome! keep rocking!

Re: Parsoid in PHP, or There and Back Again

#73

Post by znpy » Sun, Feb 16, 2020, 12:23 AM UTC

lolphp111 wrote: post #60

Why? The editor needs a frontend in javascript anyways, so why mot handle this all in real time on the client? Now they rewrote in PHP, thats probably one of the worst languages out there, and why not rewrite in something compiled if speed was the main reason for a rewrite? For me PHP sits in the middle as a poor language, and still slow compared to any compiled languages. Also i would want to see some wasm vs php be…

you probably want to do stuff on server side too.

One of the things that come to my mind is rendering in formats other than html.

wikibooks for example lets you render wikimedia pages into pdf, and that's cool. but to do that you have to parse the page server side.

Re: Parsoid in PHP, or There and Back Again

#74

Post by znpy » Sun, Feb 16, 2020, 12:32 AM UTC

lolphp111 wrote: post #60

Why? The editor needs a frontend in javascript anyways, so why mot handle this all in real time on the client? Now they rewrote in PHP, thats probably one of the worst languages out there, and why not rewrite in something compiled if speed was the main reason for a rewrite? For me PHP sits in the middle as a poor language, and still slow compared to any compiled languages. Also i would want to see some wasm vs php be…

> For me PHP sits in the middle as a poor language, and still slow compared to any compiled languages.

After switching jobs and ending up in a PHP-based company, I can say that such thing is not entirely true.

Poor language?

Not really, it does a lot of stuff and solves a lot of problems.

Still slow?

Kinda true but not really: php 7.x saw a huge improvements and rumors have it that php 8.x will be getting a JIT-compiler.

Also, from my own observation, most of php slowness derives from the fact that the usual approach to deploying a php web application means using php fpm, that starts a whole new php interpreter for each request.

This in turn derives from the fact that php was born to create "dynamic websites" as in websites that were mostly static but with some occasional dynamic page.

IMHO some framework (Laravel? Symfony? some new player?) should try and start a single php process to handle request and persist between a request and the next one.

Starting a new php process is SUPER expensive: there's the whole fork+exe overhead, I/O to load data from disk, parsing and byte-compiling. every single time. even with opcache, you might skip some of the last steps, but you'll have to re-load cache in the next execution.

Re: Parsoid in PHP, or There and Back Again

#75

Post by cscottnet » Mon, Feb 17, 2020, 2:50 AM UTC

subbu_ss wrote: post #70

lovasoa wrote: post #66

Earlier quoted context omitted.

One question: did you investigate why the PHP version was so much faster than the JS one ? Do you think the performance gains of the PHP versions could be achieved in JS, or do you use any special feature of the PHP interpreter ?

No, we haven't investigated it yet since we haven't had the time to do it. But, we've filed a task for maybe someone to look at it ( https://phabricator.wikimedia.org/T241968 ), but our hunch is that it would be be incorrect to conclude that PHP is faster from JS.

A slightly longer answer is that we looked into a number of possible reasons and it's not clear there's an easy answer. Lots of differences between the two setups, and every time we come up with an possible answer like "oh, it's the reduced network API latency" we come up with a counter like "but html2wt is also faster and it does barely any network requests". Casual investigation raises more questions than answers. So we've looked into it but don't yet have an answer that we fully believe.