[Manishearth]

> zero-copy parallel parsing of html,

zero copy yes, parallel I don't know

We do selector matching in parallel (parsing is probably serial?), layout in parallel, and offload almost all of the rendering work onto the GPU.

Not sure what you mean by "in-going data duplication". We try to be zero-copy when we can, and share as much as possible. Rust helps here; because you are free to try and share things without worrying if they will go out of scope too early, and the compiler will tell you if your guess was wrong.

[pointernil]

Thanks!

"in-going data duplication" ummm... i guess i meant ;) duplication of the incoming data (network packets->buffers->resources like html-files etc) in the sense of trying to minimize the amount of data duplicated and moved around to be used by various code-parts.

Most probably the most interesting parts are those areas where even Rust can't really "help" to prevent that. thanks

[Manishearth]

.....

grins sheepishly

As Jack mentioned in another comment (https://news.ycombinator.com/item?id=11994607), a lot of our glue is slow just because we haven't paid attention to it. Some of this is duplication of the kind you specify.

So we do do a lot of extra copying. Especially once we switched to multiprocess -- there's a ton of data being passed between processes through a copy that really should use shared memory or something. It's pretty straightforward to fix in most cases, but we just haven't gotten to it. Like many other issues we have. Servo is mostly a testbed for the smaller components, so this is to some degree okay.

My favorite example of this is that we probably contain the worst cache implementation ever. Before multiprocess, we still used threads and senders a lot. So switching to multiprocess just involved replacing certain threads with processes, and using IPC instead of regular sync::mpsc senders.

One thing that got caught in the mix was our font cache. This cache loads fonts from disk and shares them with content threads till they aren't needed anymore. It was a simple cache, implemented as an atomic refcounted weak pointer being stored in the cache while strong refcounted pointers are being handed out to content threads.

In the process world, refcounted pointers are duplicated across IPC with their refcounts reset to one. So this involves copying the whole font across IPC. Inefficient in itself.

Also, on Linux, our IPC currently assumes /tmp is tempfs (it isn't in many cases), and uses it for shared memory. So, our cache, to save us from loading fonts from disk, loads a font from disk, and each time a process wants it, stores the file to disk in /tmp and has that process load it from disk. Which is unequivocally worse than what we had :)

It's not hard to fix, though. But it's stuff like this that we still have. It doesn't have to do with Rust, just has to do with priorities. My plan here is to first get a sane IPC shared memory implementation for Linux (to be used whenever we send gobs of data across a process), and build a better caching layer over it for the font cache. (If you like OS stuff and want to help ; let me know!)

However, the individual components themselves are pretty great!

[pointernil]

Thanks for the insights!

I did not mean to criticize servo or rust in any way... Any serious and non-tiny project will have areas like those you pointed out. I just think servo (and rust as its main 'tool') is a really great endeavor on the track to multi-process/parallel/concurrent (system)programming on the larger scheme of things ;). Any 'issues' you guys trip over are for sure nice lessons... which even potentially can feed back into rust. (which was the plan all along, afaik ;) Cheers

[Manishearth]

Oh, I didn't take it as criticism. Was just slightly amused :)

Not sure the specific situations I mention can be fixed by Rust (or any language), those are design issues basically.