Closes #1643 #1644
Merged
Closes #1643 #1644
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Will it be more generalized to do something like |
|
Yeah. That sounds better. I will make the change :) |
mdamle
force-pushed
the
memory_optimization
branch
3 times, most recently
from
f44e220
to
c8e89e7
Compare
|
This is ready for review. Please take another look :) |
|
Another suggestion, I think the default allocator should be put in the template class definition, instead of the typedef: rapidjson/include/rapidjson/document.h Line 2153 in 98f52b6 which also reminds me that, we may also add a macro for the default stack allocator as well. |
This change comes up with compile time pre-processor directives to tune the behavior of rapidjson wrt memory consumption. The idea is to allow each module using this library to choose the right defaults based on how it consumes memory and what performance it expects. 1. RAPIDJSON_DEFAULT_ALLOCATOR: If defined allows you to choose CrtAllocator over MemoryPoolAllocator. If it is not defined, chooses MemoryPoolAllocator by default. 2. RAPIDJSON_DEFAULT_STACK_ALLOCATOR: If defined allows you to choose MemoryPoolAllocator over CrtAllocator. If it is not defined, chooses CrtAllocator by default. 3. RAPIDJSON_VALUE_DEFAULT_OBJECT_CAPACITY and RAPIDJSON_VALUE_DEFAULT_ARRAY_CAPACITY: If defined and set to a value, uses that value for default number of objects/array elements to be pre-allocated. If not defined, uses value of 16: the current default. Verified that all tests pass.
mdamle
force-pushed
the
memory_optimization
branch
from
c8e89e7
to
faabc25
Compare
|
Makes sense. I have pushed a new commit that uses the defaults in the class template itself. I have also added anew #define for DEFAULT_STACK_ALLOCATOR. |
|
Thank you |
|
Thanks for all the great feedback :) |
Kythera-Sam
added a commit
to MoonCollider/rapidjson
that referenced
this pull request
Jun 12, 2024
* add test for non-null-terminated token * Make GenericMemberIterator::Iterator public again (RAPIDJSON_NOMEMBERITERATORCLASS) d87b698 made all definitions of GenericMemberIterator consistent as classes (they were structs with RAPIDJSON_NOMEMBERITERATORCLASS defined), but it didn't keep the member definitions public. document.h:586:71: error: 'Iterator' is a private member of 'rapidjson::GenericMemberIterator<false, rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >' typedef typename GenericMemberIterator<false,Encoding,Allocator>::Iterator MemberIterator; //!< Member iterator for i... ^ document.h:2124:32: note: in instantiation of template class 'rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >' requested here class GenericDocument : public GenericValue<Encoding, Allocator> { * Update .travis.yml * Update .travis.yml * Update travis-doxygen.sh * Update travis-doxygen.sh * Update travis-doxygen.sh * Update travis-doxygen.sh * Disable copy constructor in GenericMember * Provide default implementations for move constructor/assignment in GenericMember * Use C++17 fallthrough tag instead of disabling warning Signed-off-by: Ross Younger <crazyscot@gmail.com> * fix some misspellings * doc: fix a typo * fix CMake policy CMP0048 warning Tencent#1154 * add contributing section in readme.md, introduced the basic cooperation process. * Remove shadow typedef Removes a duplicate and identical typedef that was causing a 'declaration shadows typedef' (-Wshadow) warning in clang. * Add vcpkg installation instructions * Allow escaped apostrophe in values (Tencent#1639) * Allow escaped apostrophe in values * Allow escaped apostrophe in values * Canonical flag name * Add translation for escaped apostrophe Co-authored-by: Milo Yip <miloyip@gmail.com> * Fix simple typo: drived -> derived (Tencent#1646) Closes Tencent#1645 * Closes Tencent#1643 (Tencent#1644) This change comes up with compile time pre-processor directives to tune the behavior of rapidjson wrt memory consumption. The idea is to allow each module using this library to choose the right defaults based on how it consumes memory and what performance it expects. 1. RAPIDJSON_DEFAULT_ALLOCATOR: If defined allows you to choose CrtAllocator over MemoryPoolAllocator. If it is not defined, chooses MemoryPoolAllocator by default. 2. RAPIDJSON_DEFAULT_STACK_ALLOCATOR: If defined allows you to choose MemoryPoolAllocator over CrtAllocator. If it is not defined, chooses CrtAllocator by default. 3. RAPIDJSON_VALUE_DEFAULT_OBJECT_CAPACITY and RAPIDJSON_VALUE_DEFAULT_ARRAY_CAPACITY: If defined and set to a value, uses that value for default number of objects/array elements to be pre-allocated. If not defined, uses value of 16: the current default. Verified that all tests pass. * Update biginteger.h (Tencent#1652) Fix intel compiler macro Tencent@de6681e#commitcomment-37645051 * PrettyWriter constructor uninitialized member (Tencent#1654) Fix Tencent#1653 * Replace RAPIDJSON_CLZLL with internal clzll (Tencent#1660) RAPIDJSON_CLZLL is defined as macro of __builtin_clzll when using gcc to compile. This introduces two issues: 1. in gcc __builtin_clzll returns int, not uint32_t. 2. __builtin_clzll return is undefined when input x is 0 See: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html This patch removes RAPIDJSON_CLZLL, merges __builtin_clzll to internal clzll with input check and return value explicit cast. Change-Id: Iac4b355dc5e5b4ed9b3f35a640b6b5537e76f22c Signed-off-by: Jun He <jun.he@arm.com> Co-authored-by: Jun He <jun.he@arm.com> * Avoid warnings when using -std=c++20 and clang 10: use three way comparision for iterators when possible. (Tencent#1667) /data/mwrep/res/osp/RapidJson/20-0-0-0/include/rapidjson/document.h:729:58: error: use of overloaded operator '!=' is ambiguous (with operand types 'rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >::MemberIterator' (aka 'rapidjson::GenericMemberIterator<false, rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >') and 'rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >::MemberIterator') for (MemberIterator m = MemberBegin(); m != MemberEnd(); ++m) * Three-way comparison for CLang 10 fix (Tencent#1679) C++20 features must enable additional functionality, not to change interface completely * Doc: Fix some typos. (Tencent#1675) * Update Visual Studio Visualizer (Tencent#1665) 1. Determine the correct type of string based on encoding 2. Omit string pointer address * ci: upgrade distro to xenial and add arm64 test cases (Tencent#1662) Start from xenial, Travis supports multiple CPU architectures. To bump to this version allows expand test coverage for more architectures. See: https://docs.travis-ci.com/user/reference/overview/#virtualisation-environment-vs-operating-system Add arm64 test cases to matrix. Change-Id: If61e2d38223dad70b542d6ec0afcf4a433c9debf Signed-off-by: Jun He <jun.he@arm.com> Co-authored-by: Jun He <jun.he@arm.com> * Add a target to RapidJSONConfig.cmake.in (Tencent#1350) This way, users can call target_link_libraries against the imported target, which is the recommended way of doing things. * Add CMake minimum version required. Interface Libraries feature is not available before CMake 3.0 Signed-off-by: Gao Mingfei <mingfei.gao@ucloud.cn> * Fixes issue Tencent#1718 * Improve surrogate handling Report a single low surrogate as kParseErrorStringUnicodeSurrogateInvalid. * Add test case for low surrogate handling * fix _BitScanReverse() usage for CE6 * fallback to the naive version for CE6 * fix naive version implementation * add unit test for clzll() * fix naive implementation for clzll() * fix unit test * fix Tencent#1778 (part 1) * Remove unnecessary wording from BSD license not needed for MIT license (fixes Tencent#528) * fix schema test compile error * suppress enum bitwise operation warnings on msvc * add body to private copy constructor & copy assignment * add return statement & comment * also initialize class member * Add implicit conversion from Object and Array to Value (Tencent#1404) Allows resolution of JSON Pointer on Object and Array * code and tests * remove debug std::cout, handle empty error object in example * remove C++ 11 enum syntax * remove C++ 11 std::string to_string() syntax * revert perftest * Revert "revert perftest" This reverts commit 221e8d5. * correct workaround for issue 1805 * restore coverage * work around issue 1089 * fix crash where simple type with sub-schema has a bad value * Fix recursive operator== call in C++20 (Tencent#1846) * code and tests * fix bracket * fix compile errors * fix platform-dependent compiler error with >> * doc: fix incorrect template parameters in EncodedOutputStream example Fix Tencent#1851 * handle internal refs properly * remove comma * correct #defines in uri.h * satisfy all compilers * satisfy all compilers 2 * satisfy all compilers 3 * Provide RAPIDJSON_HAS_CXX11 and use it for RAPIDJSON_HAS_CXX11_RVALUE_REFS and RAPIDJSON_HAS_CXX11_NOEXCEPT. * RAPIDJSON_NOEXCEPT_ASSERT should assert regardless of RAPIDJSON_HAS_CXX11_NOEXCEPT. * Safer GenericValue& operator=(GenericValue& rhs). When rhs is a sub-Value of *this, destroying *this also destroys/frees rhs, thus the following RawAssign(rhs) crashes. Address this by saving/moving rhs to a temporary first, which clears rhs and avoids its destruction with *this. The crash can be reproduced in test Value.MergeDuplicateKey by using the CrtAllocator instead of the default Document's MemoryPoolAllocator. * Test assignment from inner Value. * Provide StdAllocator, STL compatible, for use with STL types. * Tests for StdAllocator. * add traverse as pointer example * Make StdAllocator C++17-20 compatible. * Make StdAllocator C++17-20 compatible. * Handle C++17 (and C++11 with MSVC) in CI. * Don't define StdAllocator<void> from C++17. * Tests for C++17 with VS 2019. * Fix would-crash tests if the default allocator used were kNeedFree. The allocator cannot be destroyed before the Document, otherwise the Value destructor double frees. * Add rvalue copy and assignment to MemoryPoolAllocator and StdAllocator. * Tests for Allocators copy by rvalue reference. * Try some tests with -D_GLIBCXX_DEBUG and coverage with -O0. * Set RAPIDJSON_USE_MEMBERSMAP to use a (std::multi)map for object members. When RAPIDJSON_USE_MEMBERSMAP is defined, an object Value will store its members in an (re)allocated array of Members like before, but also in an std::multimap<GenericValue::Data,SizeType> where the key and value reference the corresponding Member by its Data 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 multimap is allocated separately and only its pointer is saved in this layout, so it can easily be restored in its new position. As for the old/alive iterators, they must move 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 the same complexity applies for the operations with MemberIterator or MapIterator. For FindMember() and RemoveMember(), the complexity drops from O(n) to the multimap/rbtree's O(log n). For EraseMember() it drops from O(n-m) to O((log n)-m), m representing the move/copy of the trailing members. For AddMember() though, the complexity grows from O(1) to O(log n) due to the insertion in the multimap too. 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_MEMBERSMAP (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_MEMBERSMAP is not defined, this commit does nothing (same results for perftest with regard to previous versions). Finally, the multimap is allocated and constructed using StdAllocator, so they will use the same Allocator than for any other Value allocation, and thus will benefit from the same performance/safety/security/whatever provided by the user given Allocator. * Tests for Members in std::multimap. * Turn some Tests to RAPIDJSON_USE_MEMBERSMAP in CI. * add a test that provokes a compile time error on windows * don't let the GetObject macro rewrite the GetObject method, add a GetObj alias * replace auto with concrete type * Fixed -Wshadow warning. * Improve documentation Signed-off-by: Saurabh Charde <saurabhchardereal@gmail.com> * fix coverage * remove copyright & debug statements * Use modern cmake function export to generate target * make std::string optional * remove compiler warning * remove temp debug statements * fix coverage, unit test allocators and equality * fix Uri.Match optional arg * fix coverage again * Fix Pointer::Append() crash for custom allocator on Windows Fix Tencent#1899 * equiv fix for issue 1899 * Uri Parse improvements * Fix small errors in dtoa output for certain doubles * Fix RawNumber for longer char types * Added typename * Using unsigned for WIStreamWrapper * Do not depend on c++11 conditional * Use rapidjson internal::SelectIf * No default template parameter for older compilers * No default template parameter for older compilers * Correct WIStreamWrapper * typo on documentation dom.zh-cn.md: "己于" -> "已于" * fix the warning * Support CMake none targets When trying to import rapidjson with for exemple : fetchcontent_declare(rapidjson GIT_REPOSITORY https://github.com/Tencent/rapidjson.git) if your CMake/Clang is "bare metal", exemple given : set(CMAKE_SYSTEM_NAME none) set(CMAKE_SYSTEM_PROCESSOR x86_64) set(CMAKE_C_COMPILER_TARGET x86_64-elf-none) set(CMAKE_CXX_COMPILER_TARGET x86_64-elf-none) CMake fails to process CMakeLists.txt because of the switch on UNIX/CYGWIN/WIN32 for install directory. Error is: CMake Error at cmake-build-debug-clang/_deps/rapidjson-src/CMakeLists.txt:244 (INSTALL): INSTALL FILES given no DESTINATION! * Resolve issue 1948 Correct instances of >> as they failed compilation. * Add files via upload * use softintrin on arm64ec * Sanitize the code in schema.h * Fix the alignment of placement new buffer for GenericValue. When using operator[] on a GenericValue type clang-tidy complains, appropriately, about the alignment of the buffer used for placement-new of the "dummy" GenericValue. * Revert "Fix the alignment of placement new buffer for GenericValue." * Fix the alignment of placement new buffer for GenericValue. When using operator[] on a GenericValue type clang-tidy complains, appropriately, about the alignment of the buffer used for placement-new of the "dummy" GenericValue. * Allow the macro RAPIDJSON_DEFAULT_ALLOCATOR to be used in any namespace `RAPIDJSON_DEFAULT_ALLOCATOR` uses names in the namespace `RAPIDJSON_NAMESPACE`. Replace this with a name starting in the global namespace. * Allow the macro RAPIDJSON_DEFAULT_STACK_ALLOCATOR to be used in any namespace RAPIDJSON_DEFAULT_STACK_ALLOCATOR uses names in the namespace `RAPIDJSON_NAMESPACE`. Replace this with a name starting in the global namespace. * Allow access to the template parameter StackAllocator in the GenericDocument Add the typedef declaration `StackAllocatorType` to the class template `GenericDocument`. This allows the user to access the template parameter `StackAllocator`. * fix shadowed variable * fix shadowed variable, take 2 * valuetest: fix potential write of terminating nul past the end of the destination Fixes 2 compile errors with gcc-12, eg: tesunittest/valuetest.cpp:1516:30: error: 'sprintf' may write a terminating nul past the end of the destination [-Werror=format-overflow=] test/unittest/valuetest.cpp:1516:20: note: 'sprintf' output between 2 and 11 bytes into a destination of size 10 * encdedstreamtest: fix use-after-free compile error with gcc-12 * Avoid exit-time destructors. operator[]() was recently changed to use the existing code in order to correctly align the returned pointer; however this broke -Wexit-time-destructors. Change to a method that is still correctly aligned but does not generate a destructor. * Avoid exit-time destructors. operator[]() was recently changed to use the existing code in order to correctly align the returned pointer; however this broke -Wexit-time-destructors. Change to a method that is still correctly aligned but does not generate a destructor. * Include conceptual change from PR 2001. * Try to fix MSVC build. * Make schema dtor robust against exceptions * fixes for natvis * gate definition of symmetric equality operators on impl, not lib These operators call themselves recursively if C++20 semantics are present in the compiler, regardless of standard library support for the operator; therefore the test should be on __cpp_impl_three_way_comparison, not __cpp_lib_[...]. This fixes the Value.EqualtoOperator test when the language standard is set to C++20 and the standard library does not yet define the library support macro. * delete unused variable * docs: fix simple typo, perecent -> percent There is a small typo in test/unittest/pointertest.cpp. Should read `percent` rather than `perecent`. Signed-off-by: Tim Gates <tim.gates@iress.com> * Update allocators.h Fixing compiler error on older compilers, such as SLED 11.0. cd rapidjson-master g++ -Wall -m32 -ggdb -Iinclude -O1 ./example/simpledom/simpledom.cpp -o simpledom 2>&1 | tee out.txt Changed SIZE_MAX to std::numeric_limits<size_t>::max() in code to get rid of SIZE_MAX error. * Update dtoa.h Fixed DigitGen to use proper suffix for uint64_t numeric types. Change from U suffix to ULL suffix. On SLED 11.0 compiler, code would not compile. cd rapidjson-master g++ -Wall -m32 -ggdb -Iinclude -O1 ./example/simpledom/simpledom.cpp -o simpledom 2>&1 | tee out.txt * initial * corrections * add dump of unexpected schema errors in schematest.cpp * correct address.json so tests pass * remove unnecessary templating from schema tests * fix build break * tidy up after merge from master * attempt to fix SEH * small corrections for schema.h * code & tests for openapi 2.0 & 3.0 suppprt * review comment updates * do not define operator!= in C++20 A change to the semantics of equality operator rewriting in C++20 (P2468R2: The Equality Operator You Are Looking For) means that operator== may not be rewritten with reversed operands if operator!= is also defined. Since operator!= can normally be synthesized from operator== regardless in this language standard, we can and should avoid defining those when the new language semantics are available. This fixes the compilation of tests (and probably consuming code) in C++20 onwards for compilers that implement this new semantic, including recent nightly builds of clang-16. Reference: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2468r2.html * fix a typo in error.h: literial -> literal * fix #1 * Suppress uritest * Use passed in allocator. * CMakeLists: fix optflags for ppc * Resolve conflict with Windows header about max macro * Eliminate missing prototypes warning * Check for __GNUC__ definition Wrap code checking against __GNUC__ to ensure it is defined. This can cause errors with compilers which do not define this preprocessor value. * Avoid ptrdiff between pointers to different allocations When using running both Undefined Behavior Sanitizer (UBSan) and Hardware-Assisted Address Sanitizer (HWASan) on Fuchsia, ubsan complained about a pointer overflow when computing the new token->name pointer. This happens because the initial pointer diff takes the offset between two allocations with different tags, so the arithmetic results in a very large diff that gets added to the original token->name ptr which overflows. Any arithmetic between pointers to two allocations is unspecified behavior, so hwasan+ubsan is catching a bug here. It looks like rapidjson is just attempting to update the name pointers to strings copied into the new nameBuffer_ via this arithmetic, but since these strings and the tokens are in the same buffer, the offset between them should be the same. For each token we can just get this offset and adjust the new name pointers accordingly which avoids the bad arithmetic. * Stringify NaN, Inf as null if needs * Remove empty cross-reference in comment Remove useless comment block which owns a '\see' cross-reference, but doesn't provide any data after it. This empty cross-reference triggers a compiler warning. Change-Id: I5c01d57579e5efedcb4bf17b80b06db313a61ab3 * Fixing printf format warning In the BigNestedObject test case of valuetest.c, a dynamically defined format is used that depends on the signedness of the 'SizeType' type. This allows the 'sprintf' function to use the correct format for 'SizeType'. Change-Id: I97222b699bda6c0ccfc9abbc5977c79e16605f2c * Eliminate old style cast warning Use static_cast to replace old style cast. Change-Id: I30e659c8f2aadc02750555b0f041bfd2e1c8004a * Rename to fix allocator shadowing The identifier 'allocator' in the RapidJSON StdAllocator class declaration shadows the identifier 'allocator' in the std::allocator class. To fix this, rename the 'allocator' identifier in the StdAllocator class declaration to a different name. * Fix: 'Stringify NaN, Inf as null' The code path where 'null' is written was never reached when 'writeFlags == kWriteNanAndInfNullFlag' * unit tests for 'Stringify NaN, Inf as null' * Fix object hashing in schema * Fix swapped high and low offset basis values * Add Hasher tests for objects where key eq value * Use correct format for printf Change the printf format from '%d' to '%u', matching the type of the arguments. * Fix schema regex preprocessor include logic * Fix comparision of two doubles One of multipleOf test failed because most floating-point numbers end up being slightly imprecise. And, the check of multipleOf with two double numbers using the dividend (a) and the result of multiplying the multiple after rounding down by the divisor (floor(|a|/|b|)*b) to compare. Change to using std::numeric_limits::epsilon to check the error of the division result. * Fix static_cast in regex.h In the constructor for GenericRegexSearch, there was an issue with a static_cast casting the result of the Malloc call. The issue was that the stateSet_ member is of type uint32_t*, and there was an attempt to assign an unsigned* to it. On some systems, uint32_t is not equivalent to unsigned, thus yielding a compile error for assigning pointers of different type. Change-Id: I5b5036100305510b83cc4893b784a2dc9f3e4849 * tests: Only run valgrind tests if valgrind was found valgrind is not present on all architectures (eg riscv64) and might not be installed even on supported architectures. Signed-off-by: Richard W.M. Jones <rjones@redhat.com> * fix Visual Studio 2022 (using /std:c++20) warning warning C5232: in C++20 this comparison calls ... recursively * Add RAPIDJSON_BUILD_CXX20 option The travis/appveyor files are updated to reference this option, but it is not yet enabled in any of the build configurations. * rapidjson.h: add forgotten ppc64 case * Minifiy * Kythera changes * Use correct case --------- Signed-off-by: Ross Younger <crazyscot@gmail.com> Signed-off-by: Gao Mingfei <mingfei.gao@ucloud.cn> Signed-off-by: Saurabh Charde <saurabhchardereal@gmail.com> Signed-off-by: Tim Gates <tim.gates@iress.com> Signed-off-by: Richard W.M. Jones <rjones@redhat.com> Co-authored-by: Etienne Laurin <etienne.laurin@gonitro.com> Co-authored-by: Milo Yip <miloyip@gmail.com> Co-authored-by: Eric Rannaud <e@nanocritical.com> Co-authored-by: zhao xin <esrrhs@163.com> Co-authored-by: Ross Younger <crazyscot@gmail.com> Co-authored-by: fredgan <ganshaolong@vip.qq.com> Co-authored-by: VeekXT <veekxt@gmail.com> Co-authored-by: Charles Milette <me@charlesmilette.net> Co-authored-by: piratf <piratf.me@gmail.com> Co-authored-by: Joshua Watt <JPEWhacker@gmail.com> Co-authored-by: PhoebeHui <v-phma@microsoft.com> Co-authored-by: xpahos <xpahos@gmail.com> Co-authored-by: Tim Gates <tim.gates@iress.com> Co-authored-by: mdamle <makarand.damle@gmail.com> Co-authored-by: Jun <junhe@apache.org> Co-authored-by: Jun He <jun.he@arm.com> Co-authored-by: Romain Geissler @ Amadeus <romain.geissler@amadeus.com> Co-authored-by: Nikolay <211292+kolya7k@users.noreply.github.com> Co-authored-by: 仓鼠 <zhuxx2003@gmail.com> Co-authored-by: ioannis-e <ioannis-e@users.noreply.github.com> Co-authored-by: Matteo Settenvini <matteo@member.fsf.org> Co-authored-by: Gao Mingfei <mingfei.gao@ucloud.cn> Co-authored-by: Gustav <sir.gustav.the.coder@gmail.com> Co-authored-by: Gaspard Petit <gpetit@eidosmontreal.com> Co-authored-by: Lars Klein <lars.klein@deepl.com> Co-authored-by: escherstair <ernestviga@gmail.com> Co-authored-by: Pave Pimenov <pavel.pimenov@gmail.com> Co-authored-by: Silas S. Brown <ssb22@cam.ac.uk> Co-authored-by: Xuanyi Zhou <zxy19980101@sina.cn> Co-authored-by: Krystian Chmura <krystian.chmura@gmail.com> Co-authored-by: Steve Hanson <smh@uk.ibm.com> Co-authored-by: Laurent Stacul <laurent.stacul@amadeus.com> Co-authored-by: ylavic <ylavic.dev@gmail.com> Co-authored-by: Hendrik Muhs <hendrik.muhs@gmail.com> Co-authored-by: N. Kolotov <n.kolotov@outlook.com> Co-authored-by: Saurabh Charde <saurabhchardereal@gmail.com> Co-authored-by: JackBoosY <yuzaiyang@beyondsoft.com> Co-authored-by: jack_perisich <jackperisich@gmail.com> Co-authored-by: Kyrega <philipp.stefan.womser@sap.com> Co-authored-by: Andrew <920076768@qq.com> Co-authored-by: Ivan Le Lann <ivan.lelann@gmail.com> Co-authored-by: ardb-uk <59880669+ardb-uk@users.noreply.github.com> Co-authored-by: jedwards <jonathan_edwards@mcafee.com> Co-authored-by: Malcolm Tyrrell <matyrr@microsoft.com> Co-authored-by: Adam Calhoon <adam.calhoon@ready-robotics.com> Co-authored-by: agate-pris <agate-pris@users.noreply.github.com> Co-authored-by: Leonid Terenin <leonid.terenin@mujin.co.jp> Co-authored-by: Jack·Boos·Yu <47264268+JackBoosY@users.noreply.github.com> Co-authored-by: Tom Briden <tom@decompile.me.uk> Co-authored-by: Peter Kasting <pkasting@chromium.org> Co-authored-by: Johnny Shaw <johnny.shaw@live.com> Co-authored-by: Kent Ross <k@mad.cash> Co-authored-by: jwillcox-telework <65623287+jwillcox-telework@users.noreply.github.com> Co-authored-by: Tana0910 <32482176+Tana0910@users.noreply.github.com> Co-authored-by: supperpiccle <cpluspluspython@gmail.com> Co-authored-by: Sergey Fedorov <vital.had@gmail.com> Co-authored-by: Flaviu_ <37621568+flaviu22@users.noreply.github.com> Co-authored-by: Albert Hung <albert.hung@garmin.com> Co-authored-by: Leonard Chan <leonardchan@google.com> Co-authored-by: Jihadist <tomasiche@gmail.com> Co-authored-by: Jeroen Doggen <jeroendoggen@gmail.com> Co-authored-by: Aikawa Yataro <aikawayataro@protonmail.com> Co-authored-by: Esther Wang <esther.wang@garmin.com> Co-authored-by: Bryant Ferguson <bryant.s.ferguson@gmail.com> Co-authored-by: Dylan Burr <dylan.burr@garmin.com> Co-authored-by: Richard W.M. Jones <rjones@redhat.com> Co-authored-by: Gilles Vollant <info@winimage.com> Co-authored-by: Brian Rogers <bobbymcr@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change comes up with compile time pre-processor directives to
tune the behavior of rapidjson wrt memory consumption. The idea is to
allow each module using this library to choose the right defaults based
on how it consumes memory and what performance it expects.
MemoryPoolAllocator. If it is not defined, chooses MemoryPoolAllocator by default.
RAPIDJSON_VALUE_DEFAULT_ARRAY_CAPACITY: If defined and set to a
value, uses that value for default number of objects/array elements to be pre-allocated. If not
defined, uses value of 16: the current default.
Verified that all tests pass.