| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL makes the following substitutions.
* assert.h -> cassert
* math.h -> cmath
* stdarg.h -> cstdarg
* stddef.h -> cstddef
* stdint.h -> cstdint
* stdio.h -> cstdio
* stdlib.h -> cstdlib
* string.h -> cstring
PiperOrigin-RevId: 309080151
|
| |
|
|
|
|
| |
Use clang-format to correct formatting to be in agreement with the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html). Doing this simplifies the process of accepting changes. Also fixed a few warnings flagged by clang-tidy.
PiperOrigin-RevId: 246350737
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Benchmark results below. More results at
https://github.com/google/crc32c/commit/354d61ef97eb73d4f0c1694cac6ec6116a5543e4.
New, MacBookPro13,3 with Core i7 6920HQ:
LevelDB: version 1.20
Keys: 16 bytes each
Values: 100 bytes each (50 bytes after compression)
Entries: 1000000
RawSize: 110.6 MB (estimated)
FileSize: 62.9 MB (estimated)
WARNING: Snappy compression is not enabled
------------------------------------------------
fillseq : 2.952 micros/op; 37.5 MB/s
fillsync : 43.932 micros/op; 2.5 MB/s (1000 ops)
fillrandom : 3.856 micros/op; 28.7 MB/s
overwrite : 4.053 micros/op; 27.3 MB/s
readrandom : 4.234 micros/op; (1000000 of 1000000 found)
readrandom : 3.923 micros/op; (1000000 of 1000000 found)
readseq : 0.201 micros/op; 550.8 MB/s
readreverse : 0.356 micros/op; 310.6 MB/s
compact : 436800.000 micros/op;
readrandom : 2.375 micros/op; (1000000 of 1000000 found)
readseq : 0.151 micros/op; 734.3 MB/s
readreverse : 0.298 micros/op; 370.7 MB/s
fill100K : 554.075 micros/op; 172.1 MB/s (1000 ops)
crc32c : 1.393 micros/op; 2805.0 MB/s (4K per op)
snappycomp : 3902.000 micros/op; (snappy failure)
snappyuncomp : 3821.000 micros/op; (snappy failure)
acquireload : 13.088 micros/op; (each op is 1000 loads)
Baseline, MacBookPro13,3 with Core i7 6920HQ:
LevelDB: version 1.20
Keys: 16 bytes each
Values: 100 bytes each (50 bytes after compression)
Entries: 1000000
RawSize: 110.6 MB (estimated)
FileSize: 62.9 MB (estimated)
WARNING: Snappy compression is not enabled
------------------------------------------------
fillseq : 3.000 micros/op; 36.9 MB/s
fillsync : 46.721 micros/op; 2.4 MB/s (1000 ops)
fillrandom : 3.922 micros/op; 28.2 MB/s
overwrite : 4.080 micros/op; 27.1 MB/s
readrandom : 4.409 micros/op; (1000000 of 1000000 found)
readrandom : 3.895 micros/op; (1000000 of 1000000 found)
readseq : 0.190 micros/op; 582.4 MB/s
readreverse : 0.413 micros/op; 267.6 MB/s
compact : 441076.000 micros/op;
readrandom : 2.308 micros/op; (1000000 of 1000000 found)
readseq : 0.170 micros/op; 651.2 MB/s
readreverse : 0.302 micros/op; 366.2 MB/s
fill100K : 614.289 micros/op; 155.3 MB/s (1000 ops)
crc32c : 3.547 micros/op; 1101.2 MB/s (4K per op)
snappycomp : 3393.000 micros/op; (snappy failure)
snappyuncomp : 3171.000 micros/op; (snappy failure)
acquireload : 12.761 micros/op; (each op is 1000 loads)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170100372
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change authored by vadimskipin and submitted via:
https://github.com/google/leveldb/pull/309
Changes made to support iOS builds and other architectures
without support for SSE 4.2.
db_bench reports original crc32 speed at:
crc32c : 3.610 micros/op; 1082.0 MB/s (4K per op)
with this change performance has increased to:
crc32c : 0.843 micros/op; 4633.6 MB/s (4K per op)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148694935
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Replace raw slice comparison with a call to user comparator.
Added test for custom comparators.
- Fix end of namespace comments.
- Fixed bug in picking inputs for a level-0 compaction.
When finding overlapping files, the covered range may expand
as files are added to the input set. We now correctly expand
the range when this happens instead of continuing to use the
old range. For example, suppose L0 contains files with the
following ranges:
F1: a .. d
F2: c .. g
F3: f .. j
and the initial compaction target is F3. We used to search
for range f..j which yielded {F2,F3}. However we now expand
the range as soon as another file is added. In this case,
when F2 is added, we expand the range to c..j and restart the
search. That picks up file F1 as well.
This change fixes a bug related to deleted keys showing up
incorrectly after a compaction as described in Issue 44.
(Sync with upstream @25072954)
|
| |
|
|
| |
git-svn-id: https://leveldb.googlecode.com/svn/trunk@23 62dab493-f737-651d-591e-8d6aee1b9529
|
| |
|
|
|
|
|
| |
MOE_MIGRATION=
git-svn-id: https://leveldb.googlecode.com/svn/trunk@22 62dab493-f737-651d-591e-8d6aee1b9529
|
| |
|
|
| |
git-svn-id: https://leveldb.googlecode.com/svn/trunk@21 62dab493-f737-651d-591e-8d6aee1b9529
|
| |
|
|
| |
git-svn-id: https://leveldb.googlecode.com/svn/trunk@20 62dab493-f737-651d-591e-8d6aee1b9529
|
|
|
git-svn-id: https://leveldb.googlecode.com/svn/trunk@2 62dab493-f737-651d-591e-8d6aee1b9529
|
