- Stop using FixedArray. Memory allocators have improved since then, so the wins are smaller.
- Prevent allocating SpecificField object in the stack. It is 96 bytes and stays in the stack frame even if used temporarily in the function.
PiperOrigin-RevId: 534454119
When building in debug mode, clang uses constructor type homing as an
optimization for debug info size. This means the debug info for types is
emitted at the same time as the constructor definition.
Some `*Descriptor` types in this file only have an inline constructor which is
never called (by design). Instead of properly constructing these objects, it
looks like memory is allocated elsewhere and then cast to the needed type. This
causes the compiler to never emit neither the inline constructor definition nor
the debug info for these types, which harms the debugger experience (it is also
technically undefined behavior).
This change moves their definitions out of line to the .cc file. This doesn't
solve the UB but it makes the compiler emit the definitions for the
constructors somewhere, and thus the debug info too.
PiperOrigin-RevId: 533579527
It's a pretty good guess that if all enum values are in [0, 128), that all the
varint values will be one byte long. So we can call Reserve() on the
RepeatedField, saving some malloc's while parsing.
PiperOrigin-RevId: 533489111
Don't mark a dependency as used just because it defines a package that's used, since many files can define the same package.
PiperOrigin-RevId: 533184254
Fixes#5139
Previously the fix https://github.com/protocolbuffers/protobuf/pull/5247 has removed unnecessary cast to Builder in generated Java code, and the current PR is doing a similar one for Java lite code.
After this PR, both Java and Java lite code won't have an unnecessary cast to Builder, thus #5139 will be fixed.
This change simply removed those casts to Builder for 2 methods, and the reason it will work is:
DEFAULT_INSTANCE.createBuilder method is defined in the superclass, and the return value is a generic value which is exactly the Builder class passed in.
Closes#10781
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/10781 from 1e0ng:main e8f9c982fe
PiperOrigin-RevId: 532813058
Hi,
When benchmarking proto_benchmark from fleetbench on an AArch64 target we found that clang is able to vectorize these functions and they offer better performance than the scalar alternative.
I ran //src/google/protobuf:arena_unittest on aarch64-none-linux-gnu. Should I run any other tests? Also protobuf used to have its own set of benchmarks, but I can't find these when I query all targets with bazel. Let me know if you'd like me to run anything else, I couldn't find instructions on what the full test run is.
Closes#11102
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11102 from avieira-arm:main 5552410a25
PiperOrigin-RevId: 532779004
This allows moving most of the tree logic into the .cc instead of having it duplicated on each template instantiation.
This reduces code size of the cold paths, making the hot paths more inlineable.
Make the iterator base completely untyped now that the tree fallback is untyped. More code duplication reduction, and it will allow further improvements on MapField in followup changes.
Move clearing logic to the .cc and optimize it. Having a single copy of it allows adding more logic to it without bloating the template instantiations:
- The map destructor will no longer reset the table before deleting it. That was wasted work.
- Use prefetching to load the nodes ahead of time. Even for trivially destructible nodes we need to read the `next` pointer.
- Start the clearing on index_of_first_non_null_ instead of 0.
- Check for arena==nullptr only once for the whole call instead of once per element.
PiperOrigin-RevId: 532595044
Jie Luo
Protobuf Team Bot
Protobuf Team Bot
Mike Kruskal
Matt Kulukundis
Jorge Gorbe Moya
Adam Cozzette
Justin Lebar
Jiulong Wang
1e0ng
Andre Vieira