facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-11 01:07:15 +03:00
Code Issues Projects Releases Wiki Activity
A Scalable, User-Friendly Source Control System.
650 Commits 25 Branches 62 Tags 325 MiB
Rust 45.1%
Python 20.7%
C++ 10.5%
Perl 9.1%
TypeScript 7.3%
Other 7.1%
562d34cf82
Go to file
Teng Qin 562d34cf82 Improve folly::RequestContext onSet and onUnset efficiency 
Summary:
In previous discussions, it has been pointed out that `folly::RequestContext::setContext` consumes considerable amount of CPU cycles in production environments. After some investigation, we thought that might be caused by looping over all `RequestData` instances can calling the virtual `onSet` and `onUnset` callback of them. Both the iteration and invoking virtual methods are not cheap.

As you can see from this change, most of the derived classes of `RequestData` don't override the `onSet` and `onUnset` methods. Mostly likely they are only used for per-Request tracking. So the natural idea is to skip those instances when iterating and avoid the unnecessary virtual method invoke.

I have explored the solution to dynamically examine if the `RequestData` instance added has `onSet` and `onUnset` method overridden. That is possible with GCC's PMF extension, but not [[ http://lists.llvm.org/pipermail/llvm-bugs/2015-July/041164.html | for Clang ]] and probably many other compilers. This definitely won't be very good for `folly`'s probability, even if we gate it by compiler flags.

Therefore, this Diff adds the `hasCallback` method to `RequestData` class indicating whether the instance would have `onSet` and `onUnset` overridden. To make it clear to users that they need to correctly override it in order for their `onSet` and `onUnset` callback to work, making it abstract so that user must override it to something and would aware of that.

Also made some improvements on documentation.

Reviewed By: myreg

Differential Revision: D6144049

fbshipit-source-id: 4c9fd72e9efaeb6763d55f63760eaf582ee4839e
2017-10-31 14:02:57 -07:00
common Completely redo CMakeFiles.txt and getdeps.sh for new thrift 2017-10-17 00:35:03 -07:00
eden Improve folly::RequestContext onSet and onUnset efficiency 2017-10-31 14:02:57 -07:00
external get the open source build working 2017-03-06 20:28:48 -08:00
.buckconfig move eden/fs/cli to eden/cli 2017-04-14 11:39:01 -07:00
.gitignore Initial commit 2016-05-12 14:09:13 -07:00
CONTRIBUTING.md Initial commit 2016-05-12 14:09:13 -07:00
DEFS get the open source build working 2017-03-06 20:28:48 -08:00
getdeps.py replace the getdeps.sh script with a python version 2017-03-08 16:38:36 -08:00
install Make oss install script less hacky using --out argument to buck build. 2017-02-28 12:12:35 -08:00
LICENSE Initial commit 2016-05-12 14:09:13 -07:00
PATENTS Initial commit 2016-05-12 14:09:13 -07:00
README.md Fix a typo in Eden's README.md. 2016-05-13 09:32:03 -07:00

README.md

Eden

Eden is a project with several components, the most prominent of which is a virtual filesystem built using FUSE.

Caveat Emptor

Eden is still in early stages of development. We are making it available now because we plan to start making references to it from our other open source projects, such as Buck, Watchman, and Nuclide.

The version that we provide on GitHub does not build yet.

This is because the code is exported verbatim from an internal repository at Facebook, and not all of the scaffolding from our internal repository can be easily extracted. The key areas where we need to shore things up are:

  • The reinterpretations of build macros in DEFS.
  • A process for including third-party dependencies (presumably via Git submodules) and wiring up the external_deps argument in the build macros to point to them.
  • Providing the toolchain needed to power the [undocumented] thrift_library() rule in Buck.

The goal is to get Eden building on both Linux and OS X, though Linux support is expected to come first.