Age | Commit message (Collapse) | Author |
|
|
|
|
|
ParsePartial does not check that required fields are set, which upb
also currently does not do.
This sped up proto2 reflection by 40%, but upb is still 7x faster in
a comparable test (instead of 11x, like before).
|
|
|
|
|
|
|
|
|
|
|
|
If a Lua program references the default message, it will
be copied into a mutable object.
|
|
Default values are now supported, and the Lua extension
can now create and modify individual protobuf objects.
|
|
This makes it easier to benchmark and test the
multiple possible implementations of varint decoding.
|
|
|
|
|
|
The symtab that contains them is now hidden, and
you can look them up by name but there is no access
to the symtab itself, so there is no risk of
mutating it (by extending it, adding other defs
to it, etc).
|
|
There was a bug with string referencing that prevented
strings from being recycled as often as they ought to be.
|
|
|
|
It is slower than the C decoder for now because it
falls off the fast path too often. But it can
successfully decode varints, fixed32 and fixed64.
|
|
upb_inttable() now supports a "compact" operation that will
decide on an array size and put all entries with small enough
keys into the array part for faster lookup.
Also exposed the upb_itof_ent structure and put a few useful
values there, so they are one fewer pointer chase away.
|
|
|
|
The compiler wasn't keeping upb_dstate in memory
anyway (which was the original goal). This
simplifies the decoder. upb_decode_fixed
was intended to minimize the number of branches,
but since it was calling out to memcpy as a
function, this turned out to be a pessimization.
Performance is encouraging:
plain32.parsestream_googlemessage1.upb_table: 254 -> 242 (-4.72)
plain32.parsestream_googlemessage2.upb_table: 357 -> 400 (12.04)
plain32.parsetostruct_googlemessage1.upb_table_byref: 143 -> 144 (0.70)
plain32.parsetostruct_googlemessage1.upb_table_byval: 122 -> 118 (-3.28)
plain32.parsetostruct_googlemessage2.upb_table_byref: 189 -> 200 (5.82)
plain32.parsetostruct_googlemessage2.upb_table_byval: 198 -> 200 (1.01)
omitfp32.parsestream_googlemessage1.upb_table: 267 -> 265 (-0.75)
omitfp32.parsestream_googlemessage2.upb_table: 377 -> 465 (23.34)
omitfp32.parsetostruct_googlemessage1.upb_table_byref: 140 -> 151 (7.86)
omitfp32.parsetostruct_googlemessage1.upb_table_byval: 131 -> 131 (0.00)
omitfp32.parsetostruct_googlemessage2.upb_table_byref: 204 -> 214 (4.90)
omitfp32.parsetostruct_googlemessage2.upb_table_byval: 200 -> 206 (3.00)
plain.parsestream_googlemessage1.upb_table: 313 -> 317 (1.28)
plain.parsestream_googlemessage2.upb_table: 476 -> 541 (13.66)
plain.parsetostruct_googlemessage1.upb_table_byref: 189 -> 189 (0.00)
plain.parsetostruct_googlemessage1.upb_table_byval: 165 -> 165 (0.00)
plain.parsetostruct_googlemessage2.upb_table_byref: 263 -> 270 (2.66)
plain.parsetostruct_googlemessage2.upb_table_byval: 248 -> 255 (2.82)
omitfp.parsestream_googlemessage1.upb_table: 306 -> 305 (-0.33)
omitfp.parsestream_googlemessage2.upb_table: 471 -> 531 (12.74)
omitfp.parsetostruct_googlemessage1.upb_table_byref: 189 -> 190 (0.53)
omitfp.parsetostruct_googlemessage1.upb_table_byval: 166 -> 172 (3.61)
omitfp.parsetostruct_googlemessage2.upb_table_byref: 258 -> 270 (4.65)
omitfp.parsetostruct_googlemessage2.upb_table_byval: 248 -> 265 (6.85)
|
|
|
|
|
|
|
|
|
|
|
|
It builds and you can inspect a symtab.
Still need to expose streaming and message
based interfaces.
|
|
|
|
We do this by special-casing the (unusual) zero case
and only bother checking the is_empty bit in the
zero case.
|
|
|
|
Unfortunately this degrades hash table lookup performance by
about 8%, which affects the streaming benchmark for googlemessage1
by about 5%. We could get this back at the cost of some memory,
but it would be nice to avoid that.
|
|
This fixes issue:
http://code.google.com/p/upb/issues/detail?id=1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I would prefer to find an API that is both fast and doesn't
require this, but we'll do this for now.
|
|
|
|
|
|
|
|
|
|
test_vs_proto2.googlemessage1 passes again,
with no memory leaks!
|
|
|
|
|
|
|