Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm going to be taking a serious look at this for my own projects.

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...



Modern heaps typically have some low-fragmentation technique built-in, for example, Windows ships with Low Fragmentation Heap, which is turned on by default since Vista.


What is "low-fragmentation heap"? Why would anyone want "high-fragmentation heap"? (since you imply that it's an option)


Low-fragmentation heap puts object of similar size together, so once object is freed, this memory can be reused for other object of similar size without fragmentation. Because of this is has more "slack" - unused memory at the end of the objects that are smaller than their buckets. On other hand, application in steady state is not going slowly increase it's memory use over time.

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.


Why would anyone want "high-fragmentation heap"?

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).



Aren't most of these already within boost or recent C++ standard ? I just took a look at the format and dynamic cases.


Some of them.

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.


From the OP: "Our primary aim with this 'foolishness' is to create a solution that allows us to continue open sourcing parts of our stack without resorting to reinventing some of our internal wheels."

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.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: