Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't just blindly double the buffer size #1

Closed
skamille opened this issue Jun 17, 2014 · 1 comment
Closed

Don't just blindly double the buffer size #1

skamille opened this issue Jun 17, 2014 · 1 comment

Comments

@skamille
Copy link

In the Java growByteBuffer, you blindly double the array size. This is a bug waiting to happen for some poor soul who overflows int.
One option is to investigate the internals of java.util.HashMap to see a nice way to grow arrays without overflowing. If nothing else, at least try to fail gracefully in this case.

@ghost
Copy link

ghost commented Jun 17, 2014

Good point. I will put a check for that in place shortly.

@ghost ghost closed this as completed Jun 19, 2014
aardappel pushed a commit that referenced this issue Jul 8, 2015
ghost pushed a commit that referenced this issue Dec 29, 2015
@ghost ghost mentioned this issue Jan 29, 2016
biddisco pushed a commit to biddisco/flatbuffers that referenced this issue Mar 16, 2016
Enable build against C++03 stdlib
ghost pushed a commit that referenced this issue Jan 11, 2018
Previously, FlatBufferBuilder used 3 resizable buffers:
- serialization (vector_downward)
- field offsets (std::vector)
- vtable offsets (std::vector)

Since the serialization buffer grows downwards, the bottom part of
it can be used as a "scratchpad" storage for the other two. Since
field offsets are only accumulated during table construction, and
vtable offsets only after table construction, the two can trivially
share the same storage.

Not only does this reduce the amount of allocation, it also removes
the bulk of std::vector usage from FlatBufferBuilder which was
the #1 cause of slow-down in debug mode, see e.g.:
https://stackoverflow.com/questions/36085285/any-way-to-improve-flatbuffer-performance-in-debug-c-msvc

Change-Id: I0224cf2f2a863d2d7ef762bc9163b52fdc149522
Tested: on Linux.
vglavnyy added a commit to vglavnyy/flatbuffers that referenced this issue Aug 29, 2018
unintellisense added a commit to unintellisense/flatbuffers that referenced this issue Jan 8, 2019
comius pushed a commit to comius/flatbuffers that referenced this issue Nov 5, 2020
Remove --incompatible_remove_native_* from .bazelrc. These are no-ops
for the build at this point, since we don't use the native rules. They
were added to bazelrc pre-0.20, to avoid accidental use of the native
rules, which is no longer a risk.

Also, fix the parameter ordering for core_app_chart, as *args and
**kwargs must appear last.

Closes google#1.

Change-Id: Ib1844f7a30c05624774861d78387210b5f88795b
GitOrigin-RevId: 416ad9e22a1af9d0f37b3a1aebc86939c41c13b4
ofirm93 referenced this issue in ofirm93/flatbuffers Apr 11, 2021
…ith_scalars

Make unsigned vectors consistent with scalars
dbaileychess added a commit that referenced this issue Nov 19, 2023
* Add absolute file names option (#1)

* Use ternary style for if

---------

Co-authored-by: Derek Bailey <derekbailey@google.com>
candysonya pushed a commit to candysonya/flatbuffers that referenced this issue Jan 8, 2024
* Add absolute file names option (google#1)

* Use ternary style for if

---------

Co-authored-by: Derek Bailey <derekbailey@google.com>
GerHobbelt pushed a commit to GerHobbelt/flatbuffers that referenced this issue Dec 5, 2024
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant