- 28 Apr, 2016 2 commits
-
-
Giuseppe Ottaviano authored
Summary: Use tag dispatching instead of `enable_if`: it is clearer, it sidesteps the GCC mangling bug, and more importantly the conditional doesn't leak into the symbol, making stack traces and profiles more readable. Testing on a compilation unit with 1000 `Function`s from simple lambdas. Before: ``` folly::impl::Function<int (), false>::Function<main::{lambda()#1}, {lambda()#1}>(main::{lambda()#1}&&, std::enable_if<std::integral_constant<bool, ((sizeof (std::decay<main::{lambda()#1}>::type))<=(sizeof folly::detail::function::Data::small))&&std::is_nothrow_move_constructible<std::decay<main::{lambda()#1}> >::value>::value, folly::detail::Tag>::type)::Ops::call(folly::detail::function&) ``` After: ``` folly::impl::Function<int (), false>::OpsSmall<main::{lambda()#1}>::call(folly::detail::function::Data&) ``` Note that the function type is repeated 5 times before, and only once after. This makes a large difference with long namespaces. Binary size is almost unaffected, compile times slightly better: Before: GCC opt: 22.3 seconds, 4435232 bytes Clang dev: 7.7 seconds, 5257344 bytes After: GCC opt: 18.6 seconds, 4493920 bytes Clang dev: 7.2 seconds, 5469136 bytes Reviewed By: ericniebler Differential Revision: D3231530 fb-gh-sync-id: 6aa76e7f780a8afdbfed8a378f257ceb86dce704 fbshipit-source-id: 6aa76e7f780a8afdbfed8a378f257ceb86dce704
-
Pavlo Kushnir authored
Summary: there is no need to call `std::function::invoke` for every DestructorGuard. Reviewed By: yfeldblum Differential Revision: D3229345 fb-gh-sync-id: c42f8cd05576d56b6a9b2f9d06878d9b01a36e94 fbshipit-source-id: c42f8cd05576d56b6a9b2f9d06878d9b01a36e94
-
- 27 Apr, 2016 7 commits
-
-
Christopher Dykes authored
Summary: Just like the real thing does. This was causing some issues when trying to link against glog, which expects the flags to be namespaced like this. Reviewed By: mzlee Differential Revision: D3230630 fb-gh-sync-id: a73ab3044560d561a39eb91ceee1588c147a46c5 fbshipit-source-id: a73ab3044560d561a39eb91ceee1588c147a46c5
-
Eric Niebler authored
Summary: folly::Function is causing significant compile time regressions. Reimplement it in a simpler way. These are the times for a file containing 1000 instantiations of folly::Fuction (old), folly::Function (new), and std::function with **g++ 4.8 -O3** on my CentOS7 server. | | Old `folly::Function` | `std::function` | New `folly::Function` | |--------|-----------------------|-----------------|-----------------------| | Time | 10m37s | 0m16.81s | 0m14.75s | And for the executable size: | | Old `folly::Function` | `std::function` | New `folly::Function` | |--------|-----------------------|-----------------|-----------------------| | Size | 10,409,504 | 732,150 | 562,781 | That's a **43X** improvement in compile times and an **18X** reduction in executable bloat over the old implementation. The times for **clang (trunk)** are very different: | | Old `folly::Function` | `std::function` | New `folly::Function` | |-------|-----------------------|-----------------|-----------------------| | Time | 4m6s | 0m45.27s | 0m11.78s | That's a **20X** improvement over the old implementation and almost a **4X** improvement over `std::function`. For **gcc-5.3.0**, compile times are again different: | | Old `folly::Function` | `std::function` | New `folly::Function` | |-------|-----------------------|-----------------|-----------------------| | Time | 2m49s | 0m18.99s | 0m20.70s | With gcc-5.3, the new implementation "only" compiles 8x faster than the old one, and is roughly the same as `std::function`. Reviewed By: spacedentist, ot, luciang Differential Revision: D3199985 fb-gh-sync-id: b97982a9dc3a63140510babea34988932e89f2d9 fbshipit-source-id: b97982a9dc3a63140510babea34988932e89f2d9
-
Kyle Nekritz authored
Summary: Without this, malicious inputs can crash anything using folly::parseJson. Reviewed By: yfeldblum Differential Revision: D3219036 fb-gh-sync-id: 3604a060170c0201473c420035b21b018383789c fbshipit-source-id: 3604a060170c0201473c420035b21b018383789c
-
Subodh Iyengar authored
Summary: Remove dead code in AsyncSSLSocket. Reviewed By: knekritz Differential Revision: D3226948 fb-gh-sync-id: e85823f311de2539c6aa2d6bcc3ff3aee07045bf fbshipit-source-id: e85823f311de2539c6aa2d6bcc3ff3aee07045bf
-
Sven Over authored
Summary: This bug causes failure when the test is run under ASAN. Reviewed By: meyering Differential Revision: D3229494 fb-gh-sync-id: a43c8332cc45f7892ac86cd0abb799616bca7779 fbshipit-source-id: a43c8332cc45f7892ac86cd0abb799616bca7779
-
Pavlo Kushnir authored
Summary: no need in virtual call from EventHandler. Reviewed By: yfeldblum Differential Revision: D3226960 fb-gh-sync-id: eb9c191630e1a1ac022666201100e3778eb7b611 fbshipit-source-id: eb9c191630e1a1ac022666201100e3778eb7b611
-
Jon Maltiel Swenson authored
Summary: 'get' is the most frequent memcached operation. On a get reply, we should go to heap as little as possible. This diff optimizes for this scenario, where replies have only one IOBuf field. Reviewed By: pavlo-fb Differential Revision: D3226592 fb-gh-sync-id: 92e1a1fac5735bd268691cf11990a96ae6fa8309 fbshipit-source-id: 92e1a1fac5735bd268691cf11990a96ae6fa8309
-
- 26 Apr, 2016 6 commits
-
-
Aditya Muttur authored
Summary: Currently UTF8Range has a constructor that allows you construct an object of type UTF8Range using only an object of type folly::Range. Adding a constructor so that we can construct an UTF8Range object using a std::string. Currently, void sampleMethod(UTF8StringPiece sp) {...} /* ... */ std::string str = "example"; folly::UTF8Range utf8Range(str); folly::StringPiece sp(str); sampleMethod(utf8Range); // works sampleMethod(sp); // works sampleMethod(str); // doesn't work This diff hopes to fix this issue. Reviewed By: ddrcoder Differential Revision: D3221144 fb-gh-sync-id: dd6ec4d7790d4602dccb3b63a4861d358aed3608 fbshipit-source-id: dd6ec4d7790d4602dccb3b63a4861d358aed3608
-
Mirek Klimos authored
Summary: same as D3156698, without changes in Cpp2Connection (which was the only real change in the diff) Reviewed By: haijunz Differential Revision: D3222792 fb-gh-sync-id: 245c7add837c0fc6d0bc84aa7d80b929ba2ce386 fbshipit-source-id: 245c7add837c0fc6d0bc84aa7d80b929ba2ce386
-
Christopher Dykes authored
Summary: If we don't, then anywhere we include `glog/logging.h` after the portability header will get the `DECLARE_*` and `DEFINE_*` macros undefined -_-.... Reviewed By: mzlee Differential Revision: D3220797 fb-gh-sync-id: 52907ddcd6b222fb1c6423034ea999eac5ce09ab fbshipit-source-id: 52907ddcd6b222fb1c6423034ea999eac5ce09ab
-
Michael Lee authored
Summary: This dependency is in the wrong order. Reviewed By: knekritz Differential Revision: D3224312 fb-gh-sync-id: 98d2c58b75cf5f16892d462ae1b877d06bce3faa fbshipit-source-id: 98d2c58b75cf5f16892d462ae1b877d06bce3faa
-
Pavlo Kushnir authored
Summary: Why not kill fbstring entirely? There are some legitimate use cases. For example, `folly::IOBuf` supports `moveToFbstring()` method which is impossible to implement with `std::string`. Reviewed By: joeg, snarkmaster Differential Revision: D3189410 fb-gh-sync-id: 9bb9090ca6012ac32ba9fb79041b26ec4888781f fbshipit-source-id: 9bb9090ca6012ac32ba9fb79041b26ec4888781f
-
Yedidya Feldblum authored
Summary: Retire `BOOST_STATIC_ASSERT` in favor of `static_assert`. `static_assert` is part of C++ now, so we don't need workarounds like `BOOST_STATIC_ASSERT` anymore. Partially automated: hg grep -lw BOOST_STATIC_ASSERT | xargs perl -pi -e 's~\bBOOST_STATIC_ASSERT\(([^;]*)\);~static_assert(\1, "");~g' hg grep -lw 'boost/static_assert.hpp' | xargs perl -pi -e 's,^#include <boost/static_assert\.hpp>\n,,gm' Caught most instances. Formatting and remaining instances addressed manually. Reviewed By: meyering Differential Revision: D3215944 fb-gh-sync-id: f4552d5d9bfc416ce283923abe880437a4d0cba5 fbshipit-source-id: f4552d5d9bfc416ce283923abe880437a4d0cba5
-
- 25 Apr, 2016 2 commits
-
-
Stepan Palamarchuk authored
Summary: This assignment is unnecessary, because in `for` loop we **always** call `cloneOneInto` that would assign another IOBuf to that IOBuf. Reviewed By: alikhtarov Differential Revision: D3215861 fb-gh-sync-id: ad87b99848aaae79f0870d49e0474f1abf0f28e5 fbshipit-source-id: ad87b99848aaae79f0870d49e0474f1abf0f28e5
-
Andrew Cox authored
Summary: Had this in another diff, but it caused too much test noise. So I've separated it out on it's own. Reviewed By: yfeldblum Differential Revision: D3213605 fb-gh-sync-id: 9ebfcf8430da7c66a31868032a0cef1e616ffc58 fbshipit-source-id: 9ebfcf8430da7c66a31868032a0cef1e616ffc58
-
- 23 Apr, 2016 1 commit
-
-
Sven Over authored
Summary:When dealing with universal references, std::move will move from objects that are passed as lvalue references. Instead std::forward should be used, which only moves from an object if it's passed as rvalue reference. Reviewed By: yfeldblum Differential Revision: D3200402 fb-gh-sync-id: 14be071e8498dd64cb8b2583c0cc2dd383bfebb8 fbshipit-source-id: 14be071e8498dd64cb8b2583c0cc2dd383bfebb8
-
- 22 Apr, 2016 4 commits
-
-
Hans Fugal authored
Summary:It's been awhile. Still has intern URLs (#10943549) but I'll fix that separately. Reviewed By: jsedgwick Differential Revision: D3213245 fb-gh-sync-id: ff60193ff368deaac8ca233d4289f30d8f6bb223 fbshipit-source-id: ff60193ff368deaac8ca233d4289f30d8f6bb223
-
Sven Over authored
Summary:Instead of std::function<bool(int, int)>, use folly::Function to pass callbacks to Subprocess::communicate. This makes it possible to pass non-copyable callables, which is especially interesting because Subprocess::readLinesCallback returns a non-copyable object. This diff also fixes the forwarding of the callback passed to readLinesCallback in case you pass an lvalue reference. Reviewed By: snarkmaster Differential Revision: D3169956 fb-gh-sync-id: 7a906f9a3ab50502fc04e0d83a23ca5e0201bb3e fbshipit-source-id: 7a906f9a3ab50502fc04e0d83a23ca5e0201bb3e
-
Yedidya Feldblum authored
Summary:[Folly] `get_default` and `get_ref_default` variants taking functions. Useful if the default value is computationally expensive to construct or requires IO. Reviewed By: andriigrynenko, spacedentist Differential Revision: D3189247 fb-gh-sync-id: 51c64293f8712d7590348d53cbfd892a5efd9e82 fbshipit-source-id: 51c64293f8712d7590348d53cbfd892a5efd9e82
-
Tobias Ritzau authored
Summary: The signals were represented using bytes in a pipe or using a count on an event fd (when available). This count was ever growing and caused the pipe to overflow, and in both cases you would get signals on empty queues. This diff only writes to the fd if it there are no bytes to read. Due to races there can still be multiple bytes in the pipe, but overflowing should not be possible. Instead of blindly signaling when there could be messages in the queue, the signals are now synchronized with the state of the queue so that the signals are drained when the queue is empty. This also made it possible to skip the semaphore behavior of the event fd which should improve perf. Reviewed By: dcolascione Differential Revision: D3198252 fb-gh-sync-id: 39e620b10c254ffcacabc4c5ac36950a215d4803 fbshipit-source-id: 39e620b10c254ffcacabc4c5ac36950a215d4803
-
- 21 Apr, 2016 2 commits
-
-
Taiyuan Zhang authored
Summary: as titled. When I tried re-adding all functions after cancelAllFunctions, it throws error. This is because it doesn't reset currentFunction to null. Reviewed By: jjs0 Differential Revision: D3209237 fb-gh-sync-id: 5b6e2d967fc3c0986320d23b8d61eb1bfbff8940 fbshipit-source-id: 5b6e2d967fc3c0986320d23b8d61eb1bfbff8940
-
chenkan authored
Summary: Closes https://github.com/facebook/folly/pull/401 Reviewed By: yfeldblum Differential Revision: D3207682 Pulled By: snarkmaster fb-gh-sync-id: 617aeec0e6fe1f46d2464df4b72a3e91c953dc12 fbshipit-source-id: 617aeec0e6fe1f46d2464df4b72a3e91c953dc12
-
- 20 Apr, 2016 7 commits
-
-
Michael Lee authored
Summary: Add more compatibility for missing gflags Reviewed By: yfeldblum Differential Revision: D3202560 fb-gh-sync-id: d25e4abfe8ceee9fb329c9ba12d259d1d03d4974 fbshipit-source-id: d25e4abfe8ceee9fb329c9ba12d259d1d03d4974
-
Marcelo Juchem authored
Summary: these macros are generally useful for other higher-order macros Reviewed By: yfeldblum Differential Revision: D3194777 fb-gh-sync-id: 667fc51c681786ad422309ee463881dc22c972f7 fbshipit-source-id: 667fc51c681786ad422309ee463881dc22c972f7
-
Michael Lee authored
Summary:Clean up a deprecation warning for JSONSchema's use of Singleton. This is in experimental, so the interface change should be reasonable.. Reviewed By: agoder Differential Revision: D3203348 fb-gh-sync-id: 3283c7d9c507a545f3217eb5afc3734eb047b833 fbshipit-source-id: 3283c7d9c507a545f3217eb5afc3734eb047b833
-
Michael Lee authored
Summary: find replace 's/{([0-9, a-z"-]+)}/dynamic::array(\1)/g' Reviewed By: agoder Differential Revision: D3203454 fb-gh-sync-id: 064bb2bdd0e19a80da32e8f4eb730fc4268d7cad fbshipit-source-id: 064bb2bdd0e19a80da32e8f4eb730fc4268d7cad
-
Mirek Klimos authored
Summary:There're currently two ways to set RequestContext - RequestContext::create() - creates new context and sets it - RequestContext::setContext(context) - sets context previously captured by saveContext In most cases, the RequestContext is set back after the request is processed but sometimes it's not (especially with RequestContext::create). We want to measure cpu time for a request by measuring the total cpu time when a RequestContext is set, so we need to make sure that it's properly reset after the thread is done with the request. Scope guards can help us with that. Reviewed By: haijunz Differential Revision: D3156698 fb-gh-sync-id: 7c3eb06c1cc27849071625011bf64c5ad36c0612 fbshipit-source-id: 7c3eb06c1cc27849071625011bf64c5ad36c0612
-
Alexey Spiridonov authored
Summary: Before this fix, the callback would silently ignore `ret == -1` if the error isn't `EAGAIN`. Reviewed By: spacedentist Differential Revision: D3193845 fb-gh-sync-id: e4a7aa37de7dab8ebe0633dd9888d8adc11dd1c2 fbshipit-source-id: e4a7aa37de7dab8ebe0633dd9888d8adc11dd1c2
-
Michael Lee authored
Summary: `__attribute__((no_sanitize("address")))` is not valid in clang 3.6 and earlier Reviewed By: skotchvail Differential Revision: D3197412 fb-gh-sync-id: bd555b030fe48268988299dd88b9b7aea54c1a73 fbshipit-source-id: bd555b030fe48268988299dd88b9b7aea54c1a73
-
- 19 Apr, 2016 2 commits
-
-
Michael Lee authored
Summary: ^^^ this is a stack overflow in the test, and a possible stack or heap overflow. Reviewed By: dcolascione Differential Revision: D3151717 fb-gh-sync-id: b4f0660ebbb89139dff003870e132c312068d9a8 fbshipit-source-id: b4f0660ebbb89139dff003870e132c312068d9a8
-
Mark Isaacson authored
Summary: This function is being proposed in WG21, the C++ standards body for inclusion in the STL via the Library Fundamentals v2 TS. Using the normal constructor for a std::array with an initializer list introduces a source of coupling between the # of elements you put in the initializer list and the size of the array you specify as a template argument. Worse still, if you put less things in the initializer list than the template argument specifies, it doesn't warn you that you've probably made a pretty devious and subtle error. With this function your array size will always be the same as the # of things you actually put in it. What's more, in some cases this can deduce the type of the elements as well. Reviewed By: yfeldblum Differential Revision: D3164432 fb-gh-sync-id: beceaae2ee01cd5f93dec86cf36efdb78a28b4a3 fbshipit-source-id: beceaae2ee01cd5f93dec86cf36efdb78a28b4a3
-
- 18 Apr, 2016 3 commits
-
-
Mirek Klimos authored
Summary:There're currently two ways to set RequestContext - RequestContext::create() - creates new context and sets it - RequestContext::setContext(context) - sets context previously captured by saveContext In most cases, the RequestContext is set back after the request is processed but sometimes it's not (especially with RequestContext::create). We want to measure cpu time for a request by measuring the total cpu time when a RequestContext is set, so we need to make sure that it's properly reset after the thread is done with the request. Scope guards can help us with that. Reviewed By: haijunz Differential Revision: D3156698 fb-gh-sync-id: cfb678531810e8be5faaf02cb7803bd247557e42 fbshipit-source-id: cfb678531810e8be5faaf02cb7803bd247557e42
-
Brian Walker authored
Summary: Add some logging to figure out the state of the Qeueu when the write error happens. Differential Revision: D3190882 fb-gh-sync-id: 6515d77df8aa3086922cb4053f2e437f3e527a36 fbshipit-source-id: 6515d77df8aa3086922cb4053f2e437f3e527a36
-
Sven Over authored
Summary:folly::fibers does not use folly::MoveWrapper anymore, so no need to include that header file. Reviewed By: yfeldblum Differential Revision: D3169374 fb-gh-sync-id: 2409b46156843fb0a1454b560c42186f1c412988 fbshipit-source-id: 2409b46156843fb0a1454b560c42186f1c412988
-
- 16 Apr, 2016 2 commits
-
-
Sven Over authored
Summary:This is the last place in folly that uses MoveWrapper (other than the MoveWrapper implementation itself and its tests, of course). Instead of using a MoveWrapper, the object in question is moved into the lambda using C++14 syntax, and the lambda is moved in a call to EventBase::runInEventBaseThread which is possible now that the EventBase methods accept non-copyable callbacks. Reviewed By: yfeldblum Differential Revision: D3169316 fb-gh-sync-id: 2dcb1a523ac417f4619c607898e58b572648e3da fbshipit-source-id: 2dcb1a523ac417f4619c607898e58b572648e3da
-
Andrii Grynenko authored
Summary:Renamed AtomicLinkedList to AtomicIntrusiveLinkedList. AtomicLinkedList is a simple AtomicIntrusiveLinkedList wrapper, which handles intrusive list hook. Reviewed By: yfeldblum Differential Revision: D3188171 fb-gh-sync-id: 0823b04a48336d65e0a6a8cd412c75f52afe02b9 fbshipit-source-id: 0823b04a48336d65e0a6a8cd412c75f52afe02b9
-
- 15 Apr, 2016 2 commits
-
-
Michael Lee authored
Summary:9ab69bc7 removed `__APPLE__` around the strndup definition because it is defined on modern OSX. But there was another reference in String.cpp. Fixing that. Reviewed By: yfeldblum Differential Revision: D3186360 fb-gh-sync-id: 709c3b93cd22945e2237412637929df1979526c1 fbshipit-source-id: 709c3b93cd22945e2237412637929df1979526c1
-
Christopher Dykes authored
Summary:Although, according to the manpage, these functions are defined in `strings.h`, but they are also defined in `string.h`. We never actually use these functions via `strings.h`, and instead only ever reference them via `string.h`. To keep things sane, lets just move the functions into `string.h` and kill `strings.h`. Reviewed By: yfeldblum Differential Revision: D3181596 fb-gh-sync-id: 8a474df510ddafc4c595b08b809a7c33e3256177 fbshipit-source-id: 8a474df510ddafc4c595b08b809a7c33e3256177
-