Revision 3f622152102075c3973697da8c562c423b45cd81 authored by Andrew Kryczka on 19 November 2016, 00:54:09 UTC, committed by Facebook Github Bot on 19 November 2016, 01:09:11 UTC
Summary:
Since a RangeDelAggregator is created for each read request, these heap-allocating member variables were consuming significant CPU (~3% total) which slowed down request throughput. The map and pinning manager are only necessary when range deletions exist, so we can defer their initialization until the first range deletion is encountered. Currently lazy initialization is done for reads only since reads pass us a single snapshot, which is easier to store on the stack for later insertion into the map than the vector passed to us by flush or compaction.

Note the Arena member variable is still expensive, I will figure out what to do with it in a subsequent diff. It cannot be lazily initialized because we currently use this arena even to allocate empty iterators, which is necessary even when no range deletions exist.
Closes https://github.com/facebook/rocksdb/pull/1539

Differential Revision: D4203488

Pulled By: ajkr

fbshipit-source-id: 3b36279
1 parent 41e77b8
Raw File
.gitignore
TARGETS
make_config.mk

*.a
*.arc
*.d
*.dylib*
*.gcda
*.gcno
*.o
*.so
*.so.*
*_test
*_bench
*_stress
*.out
*.class
*.jar
*.*jnilib*
*.d-e
*.o-*
*.swp
*~
*.vcxproj
*.vcxproj.filters
*.sln
*.cmake
CMakeCache.txt
CMakeFiles/
build/

ldb
manifest_dump
sst_dump
column_aware_encoding_exp
util/build_version.cc
build_tools/VALGRIND_LOGS/
coverage/COVERAGE_REPORT
.gdbhistory
package/
.phutil_module_cache
unity.a
tags
rocksdb_dump
rocksdb_undump
db_test2

java/out
java/target
java/test-libs
java/*.log
java/include/org_rocksdb_*.h

.idea/
*.iml

rocksdb.cc
rocksdb.h
unity.cc
java/crossbuild/.vagrant
.vagrant/
java/**.asc
java/javadoc

scan_build_report/
t
LOG

db_logs/
tp2/
fbcode/
fbcode
back to top