derive: make sure the size_hint is collected#700
Conversation
Make it a `#[must_use]` newtype to ensure that the every `size_hint`
contributes to the total, to get a better estimate for the rendered
size. By making the type `#[must_use]`, a few missing size hint
additions were found, e.g. text before `{% continue %}`.
f8f5093 to
5b84774
Compare
ed1c130 to
19e2825
Compare
| } | ||
| "#, | ||
| &[], | ||
| 12, |
There was a problem hiding this comment.
I added the last commit that explains how size_hint in a loop is calculated, because I was confused how 8 characters in a loop could equal an estimate of 12:
((8 * 3) + 0) / 2 == 12.
^ then ^ else
|
I have to admit I tend to skip the size hint a lot. ^^' Well done! |
|
That's why But I'm not very confident that our size_hint is even remotely accurate, regardless if it is accumulated or not. :D |
|
I was actually wondering if it's actually that useful... |
|
I never tried to measure it myself, or read too deeply into the matter, but it seems rust's vector growth implementation (new capacity = old capacity * 2) is the worst implementation of the good implementations (linear growth is much worse). See e.g. facebook/folly/FBVector.h. That why one shouldn't start with an empty String in rust, but that's also why an estimation that is just shy of the actual number is very bad in rust (overallocation, fragmentation). Some alternative string implementations are quite a bit faster than the built-in String, e.g. compact_str, that in addition has a small string optimization. |
Make it a
#[must_use]newtype to ensure that the everysize_hintcontributes to the total, to get a better estimate for the rendered size. By making the type#[must_use], a few missing size hint additions were found, e.g. text before{% continue %}.