• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

Tencent / rapidjson / 2142
100%
master: 100%

Build:
Build:
LAST BUILD BRANCH: id-and-ref
DEFAULT BRANCH: master
Ran 17 Apr 2019 01:36PM UTC
Jobs 2
Files 32
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

pending completion
2142

Pull #1485

travis-ci

web-flow
Make use of an (std::multi)map for object members, if #defined.

When RAPIDJSON_USE_MEMBERS_MAP is defined, an object Value will store
its members in an (re)allocated array of Members like before, but also
in an std::multimap<StringRef,SizeType> where the key and value
reference the corresponding Member by its name and index in the array,
respectively, and in a relocatable manner.

The layout of the members map/array is now:
 {multimap}<>{capacity}<>{Member[capacity]}<>{multimap::iterator[capacity]}
where <> stands for the RAPIDJSON_ALIGN-ment of each part, if needed.

This layout needs to be reallocated when the current capacity is
exhausted, which requires to take care of the multimap and its iterators
explicitely; the former (likely not a POD) can simply be saved/restored
by swapping (twice), and the old/alive iterators must be moved to their
new offset (according to the new capacity).

With this in place, it's immediate to get the multimap::iterator from a
MemberIterator and vice versa, thus Find/Remove/EraseMember() working on
a MemberIterator keep the same complexity (O(1) for find/remove, and
still O(n-m) for EraseMember() due to the move/copy).

For operations by name, the lookups complexity switches from O(n)/linear
to the multimap's, usually rbtree's O(log n)/logarithmic, including for
AddMember() which without RAPIDJSON_USE_MEMBERS_MAP is otherwise O(1).

Consequently parsing will be slower, up to ~20% measured in perftests on
my laptop (since it's mainly composed of insertions). But later work on
the Document [usually the goal of parsing...] will be much faster; the
new DocumentFind perftest included in this commit is 8 times faster with
RAPIDJSON_USE_MEMBERS_MAP (still on my laptop). Overall the tests are 4%
slower (mainly composed of parsing), and notably 15% slower for schemas
parsing/validation (which supposedly comes from the larger JSON files
parsing, still). As a side note, when RAPIDJSON_USE_MEMBERS_MAP is not
defined, this commit ... (continued)
Pull Request #1485: Member map

182 of 182 new or added lines in 2 files covered. (100.0%)

5196 of 5201 relevant lines covered (99.9%)

1452876.28 hits per line

Jobs
ID Job ID Ran Files Coverage
11 2142.11 (CONF=debug ARCH=x86 CXX11=ON GCOV_FLAGS='--coverage') 17 Apr 2019 01:36PM UTC 0
99.9
Travis Job 2142.11
12 2142.12 (CONF=debug ARCH=x86_64 GCOV_FLAGS='--coverage') 17 Apr 2019 01:38PM UTC 0
99.92
Travis Job 2142.12
Source Files on build 2142
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #2142
  • Pull Request #1485
  • PR Base - master (#2140)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc