Great write-up. Thank you. I wouldn't have guessed. The upshot of this whole thing is that Vec is for mutable collections and when you're done you make a boxed slice.
Identifying Rust's collect: >() memory leak footgun
31–40 of 129 posts
Re: Identifying Rust's collect:<Vec<_>>() memory leak footgun
#32This is a good time to check how your code performs in beta vs stable. This particular case is new in beta and it would be interesting to catch regressions before they land. Someone already filed this as a bug: https://github.com/rust-lang/rust/issues/120091
This re-use trick seems clever, but definitely needed more consideration before merging IMO. Re-use where we can determine the size & alignment are a perfect match ought to be a win, but the other cases seem very situational. And The8472's attitude here seems unlikely to lead to a better Rust.
Re: Identifying Rust's collect:<Vec<_>>() memory leak footgun
#33Cross posting my comment from reddit[1] because I think it's interesting. ----- Nice post. I love calling attention to this. Just a few months ago, I ran into the ~same~ similar problem, although it wasn't caused by `collect()`. It was caused by "normal" `Vec` usage: https://github.com/BurntSushi/aho-corasick/commit/474393be8d... The issue appeared when building large Aho-Corasick automatons. Otherwise, it usually do…
Just a somewhat tangent thought: do you know of any tricks to speed up the construction phase of Aho Corasick? A recent problem of mine needed to use Aho Corasick but with several million strings in the dictionary it took a bit longer than I thought to construct it. Any tricks you know of to speed up construction? Don't particularly care about memory.
Re: Identifying Rust's collect:<Vec<_>>() memory leak footgun
#34It took me a few extra seconds to parse the headline. ("footgun" didn't help) Is >() perhaps to become another ¯\_(ツ)_/¯ ?
It's interesting that HN zapped the second colon. The headline here (at time of my posting) is:
"Identifying Rust's collect:>() memory leak footgun"
but the actual title of the blog post is:
"Identifying Rust's collect::>() memory leak footgun"
That extra colon matters to Rust's syntax.
Re: Identifying Rust's collect:<Vec<_>>() memory leak footgun
#35Cross posting my comment from reddit[1] because I think it's interesting. ----- Nice post. I love calling attention to this. Just a few months ago, I ran into the ~same~ similar problem, although it wasn't caused by `collect()`. It was caused by "normal" `Vec` usage: https://github.com/BurntSushi/aho-corasick/commit/474393be8d... The issue appeared when building large Aho-Corasick automatons. Otherwise, it usually do…
Just a somewhat tangent thought: do you know of any tricks to speed up the construction phase of Aho Corasick? A recent problem of mine needed to use Aho Corasick but with several million strings in the dictionary it took a bit longer than I thought to construct it. Any tricks you know of to speed up construction? Don't particularly care about memory.
Hmmm. The phrasing of your question is a little ambiguous. I could interpret it two ways:
1. "Do you know if there are any config knobs in the aho-corasick crate that will speed up construction?"
2. "I have my own implementation of Aho-Corasick and construction isn't as fast as I hoped. What kinds of tricks can I employ to make my own implementation faster?"
I'd be happy to try and answer either of these, but I think it would be better to ask with a concrete example on the issue tracker Discussions: https://github.com/BurntSushi/aho-corasick/discussions
All of the tricks I know about (and I judged to be worth doing) are in the aho-corasick crate. There's really just no getting around the fact that you need to first build a trie (which requires visiting every byte in every pattern) and then do a breadth-first search across the entire trie to setup failure transitions. Making construction substantially faster probably requires some kind of innovation in those two parts at a fundamental level.
You can also cheat at this. That is, by designing your Aho-Corasick automaton to be zero-copy deserializable. The DFAs in regex-automata support this. I waver on whether to do this for aho-corasick, because it acts like a straight-jacket for evolving the internals of the library.
Re: Identifying Rust's collect:<Vec<_>>() memory leak footgun
#36It took me a few extra seconds to parse the headline. ("footgun" didn't help) Is >() perhaps to become another ¯\_(ツ)_/¯ ?
Not sure what you're asking. At risk of loosely explaining what you may already know, `>` is a generic parameter `` with the type `T` specified as `Vec`. Vec also has a param, ``, where the type is ignored - as the compiler can figure that out.
Sidenote, `>` is missing the best part - the fish head, to become `::>`, aka `::` - the Turbo Fish :D
I admit to using this syntax more than necessary just so i can write a turbofish :D
edit: Wait no, `` is the head - isn't it. hah. So i guess it's missing the fins? /shrug
Re: Identifying Rust's collect:<Vec<_>>() memory leak footgun
#37> It’s also an illustration of how an optimization in one place can lead to bugs downstream by violating programmers’ expectations. This touched upon a pet peeve of mine for its resemblance with all the talk about undefined behaviour in C and C++. Programmers’ expectations are not codified and do not need to be respected: international standards do.
>> Programmers’ expectations are not codified and do not need to be respected That's pretty negative attitude - my immediate gut response was "and neither do yours". But Rust isn't an ISO standard and is still in development. Even if we do think in those terms, people developing a standard have IMHO an obligation to the people who will be using the standard.
To be a bit pedantic, the people using the C++ standard are mostly compiler engineers.
Re: Identifying Rust's collect:<Vec<_>>() memory leak footgun
#38I appreciate the mention of Box. I've never (or at least very rarely?) seen people using it, even in rustc, although I'm sure there's somewhere in the compiler that uses it. I've kind of gotten the feeling that Box is frowned upon as a needless optimization because the one-word storage difference is so minimal, but I appreciate having the immutable size semantics as a way of ensuring no extra allocations occur by way of the methods on Vec.
Re: Identifying Rust's collect:<Vec<_>>() memory leak footgun
#39Earlier quoted context omitted.
>> Programmers’ expectations are not codified and do not need to be respected That's pretty negative attitude - my immediate gut response was "and neither do yours". But Rust isn't an ISO standard and is still in development. Even if we do think in those terms, people developing a standard have IMHO an obligation to the people who will be using the standard.
To be a bit pedantic, the people using the C++ standard are mostly compiler engineers.
I mean sure, so for those people WG21 does them a great service, in most cases they can say "Oh that's IFNDR" [Ill-formed; No Diagnostic Required] or "That's UB" and so it's not the compiler's fault your program doesn't work and they can close your ticket as NOTABUG if they want.
My guess is that all or almost-all non-trivial C++ projects trigger IFNDR and thus have no actual meaning per the ISO standard language. They do work, more or less, but that's just convention and can be taken away at any time or for any reason. Header files, use of concepts, unfortunate algorithmic goofs, careless naming, there are a billion† ways to trigger IFNDR in C++ and by definition that's fatal to your correctness.
† A billion is likely an overestimate, but WG21 has no formal inventory of IFNDR in the sprawling ISO document so, who knows.
Re: Identifying Rust's collect:<Vec<_>>() memory leak footgun
#40Cross posting my comment from reddit[1] because I think it's interesting. ----- Nice post. I love calling attention to this. Just a few months ago, I ran into the ~same~ similar problem, although it wasn't caused by `collect()`. It was caused by "normal" `Vec` usage: https://github.com/BurntSushi/aho-corasick/commit/474393be8d... The issue appeared when building large Aho-Corasick automatons. Otherwise, it usually do…
What we need is a page-based Vec that mmaps (anon) for the storage but leaves the unused portions zero-bytes and therefore not part of RSS until actually required. (And when clearing/shrinking sections, madvise DONTNEED the pages). That is, the vec could expand to areas much larger than the actual used size, but this would have no effect on process RSS until those pages get dirtied with actual data.
Is this not going to be more or less what the memory allocator backing Vec does under the hood anyway?