Hacker News new | past | comments | ask | show | jobs | submit login
Measuring data structures: Firefox (C++) vs. Servo (Rust) (valgrind.org)
90 points by Ygg2 on June 1, 2015 | hide | past | favorite | 26 comments



Hi, I'm the author of the post.

As others have explained, this is a draft, and wasn't intended for wide consumption. The easiest way I've found to show people an unpublished WordPress blog post draft is to just "save page as" in the browser and then put the resulting file up somewhere. I've done this before without problem, but this is the first time I've sent the link to a public mailing list. Lesson learned! Next time I'll send it privately to the relevant people and mark it clearly as a draft. (Or if anyone can tell me a better way to circulate a WordPress draft -- one that works for a blog that is aggregated on planet.mozilla.org -- I'd be happy to hear it.)

I've stripped out all the WordPress links and stuff from the draft post, because that was confusing lots of people. I've also added a big header at the top explaining it's a draft.

The final post, which won't be much different from this version, will go up on my blog (http://blog.mozilla.com/nnethercote/) in the next day or two.

Apologies for the confusion!


There hasn't been much meaningful discussion in this thread, and I don't think it will hurt anyone to wait a couple days for your post to be ready. So we'll bury this one and invite you (or anyone) to submit it then.


Ha, perfectly reasonable. Sharing a draft post is an interesting question though, and one I never found a good way to do back when I wrote some wordpress blog posts at a previous job. And according to wordpress.stackexchange[0] (there seems to be a stackexchange site for everything...), there is no easy way to do it.

[0]: http://wordpress.stackexchange.com/questions/107062/how-do-i...


Uh, this was a draft, and wasn't supposed to be posted until it was put up on the research blog :/


I apologize, I didn't understood it wasn't meant to be posted. Sorry :(


His personal blog has a following too, it's in my rss feed at least.


Yeah, but this wasn't published there either. Nicholas sent an email to the dev-servo list asking for review, but it's still an unpublished draft :)


Weirdly enough, when you go to this website, you appear to be logged in as Nicholas Nethercote: http://imgur.com/2tg1rOG


My guess is he's using a wordpress plugin that does static caching and it's being clumsy.


It's the Wordpress draft view. It's sort of broken; I've seen this before.


why is caching so hard to keep track of?


There are four hard problems in computer science: naming things, cache invalidation, and off-by-one errors.


FWIW, I've always heard the joke as "There are two hard problems....", which I find a little funnier because it starts the same as the original quote by Phil Karlton and just adds the joke at the end.


haha, thanks. I haven't heard of any of these. Sounds like a good opening for a presentation.


I know it as

naming things, cache invalidation and concurrency


There's five, you forgot regexes.


I noticed that, too :) But when you click on add a post or anything, it asks for creds.


For what it is worth, this is just a draft.


This is great to see, but I expect that once we have memory instrumentation implemented in Servo that we won't particularly like the initial results. :) I'm guessing that the language still needs some more work before we can start being fully competitive with Gecko, specifically in the areas of virtual structs and non-zeroing drop.

(I'd be happy to be proven wrong, though!)


Certainly, as njn has brought online each new memory profiling feature, he's discovered something ridiculous we were doing in Servo (e.g., copying things we thought we weren't; continuous memory leaks; poor use of underlying native gfx buffers, etc.). I suspect that in the near term there's plenty of low-hanging "Servo is doing something dumb" fruit to keep us busy while we log some Rust implementation issues for the smaller things.


Maybe I'm mistaken, but it seems to me that the alignment between elements (at least in C++) is not being taken in account (or maybe I've misunderstood something).


The size of each individual object is determined by calling malloc_usable_size on the block itself, so this includes any internal alignment, as well as any padding from the allocator after the object proper.

So, you get the size of the object, using the callback. Then, if the object has fields that point to other objects, you call the reporter on those fields. Then those two quantities are totaled.


Ah, now I see, and it explains the two accumulators. Thanks!


`#[ignore_heap_size_of = "Because it is a non-owning reference."] pub image: Arc<Image>,`

Wouldn't it be possible to make the annotation smart enough to distinguish between an owning and a non-owning reference?


It's easy to do that, we can just put known_heap_size invocations for these.

The reason this is ignored is that we want to figure out how we want to handle things like this (and haven't yet). We can ignore them, count them as <size>/<refcount>, or count their entire size for each owner. Depends on which one is more important for tracing memory bloat.


It would be easier to have an implementation for `Arc<T>` which either returns 0, or divides by the refcount.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: