The push_back() semantics features the standard array doubling technique, but only up to 4 KB; jemalloc can't grow in-place anything smaller than this, so a copy is required. Beyond that cut-off, push_back() will instead grow by 1.5 times the capacity to prevent too much "slack" memory from accumulating.
I could understand why you would object to both, but why only the lower level language.
Are you getting confused between tptacek and me?
I recently created a private memory allocator so the discussion on the page is somewhat interesting...
Only a tiny minority of objects are genuinely non-relocatable:
Hmm, I'm not exactly what is meant here. Moving a block of memory from here to there in the most general case will leave your pointers dangling and crash you in no short order. Things that pointed to the data you moved just don't any more. If you are disciplined and don't have raw pointers in the block moved, you're good. But as far as I know, that situation requires a very complete understanding of the data in the block you are moving. You can do that. It's just not easy or something that makes sense to stuff "anything" into.
std::string is a key exception to this, but fbstring is not.
In addition, it does not support concurrent growth.
- It requires that its members be relocatable and uses memmove to speed up move operations.
I like Format: https://github.com/facebook/folly/blob/master/folly/docs/For...
Histogram is going to come in handy. :)
fbstring seems to be exactly what the doctor ordered.
I like the emphasis on cooperating with the memory allocator in fbstring and fbvector. If the entire library does that, that's going to a big win for long-running programs: memory fragmentation can slowly increase program footprint, requiring the use of fancy arena allocators etc.
I had fun reading their vector doc: https://github.com/facebook/folly/blob/master/folly/docs/FBV...
I like dynamic: https://github.com/facebook/folly/blob/master/folly/docs/Dyn...
Also it puts consequently allocated objects (of different size) far away (and thus reduces cache locality), which, in turn may reduce performance for some "allocate a lot of stuff at the beginning and then serve it", etc scenarios, but this is pretty esoteric problem.
Benefits outweigh the concerns, so most apps benefit from the low-fragmentation heaps.
For short-lived processes, it's faster and uses less memory. The code is also simpler (important if you're writing a malloc in the mid-1980s).
For example Boost.Spirit.Karma is an order of magnitude faster than sprintf (I don't know compared to fbformat), with the drawback of a very long compile time (see here: http://tinodidriksen.com/2010/02/07/cpp-convert-int-to-strin...).
Arena, SmallLocks and AtomicHashMap will have to challenge Intel TBB. I submit TBB will be better, but I haven't done the benchmarks.
As for the rest, some of the stuff is simply outdated.
There's better stuff than Synchronized in the C++11 standard. Foreach doesn't make sense with lambdas.
Some of the headers are just trivial and useless functions (MapUtil.h, IntrusiveList.h, Random.h...), etc.
I'm a bit disappointed.
And: "we think C++ developers might find parts of this library interesting in their own right."
I think the key thing is that these are some basic pieces that a lot of FB's internal C++ code depends on. These pieces are being made available as a stepping stone to open sourcing more significant work.
We might unify that with fbvector eventually.