New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 681080 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 715175



Sign in to add a comment

Mojo C++ bindings: compare serialization strategies: calculate-before-serialize vs grow-buffer-as-needed

Project Member Reported by yzshen@chromium.org, Jan 13 2017

Issue description

Currently, in order to serialize an object, the bindings calculate its size; allocate a buffer with the size; serialize.

It would be nice to compare that with a different strategy: grow the buffer when necessary without calculating size at the beginning.

In some cases, the cost of size calculation may be bigger than potential reallocations:
- some messages may be smaller than the default allocation size so skipping calculation is a net win.
- some messages may have such a complex structure that even reallocation is cheaper than walking the structure to calculate the size.

By getting rid of the size calculation stage, we can also easily guarantee that every data field is accessed only once during serialization (instead of twice as we do today).
 

Comment 1 by yzshen@chromium.org, Jan 13 2017

One possible way of comparing the two:

- Modify chrome to include both serialization solutions. For each outgoing Mojo message, we run both and collect perf data.
- Use chrome to do some typical task (e.g., browse popular web pages). 
- Look at the perf data collected to determine whether grow-buffer-as-needed is a better solution and also what the default buffer size should be.

Comment 2 by dcheng@chromium.org, Mar 24 2017

Cc: peter@chromium.org
https://codereview.chromium.org/2762303002/ is an example CL that becomes more complicated if we try to make all the getters efficient.

Comment 3 by yzshen@chromium.org, Apr 25 2017

Blocking: 715175
https://chromium.googlesource.com/chromium/src/+/3ab0a53354e466b4da17cce0f7e59def76fc6190/gpu/ipc/common/memory_stats_struct_traits.h#40 is another example of something that's unintentionally more expensive than it should be.
Cc: -roc...@chromium.org rockot@google.com
Status: WontFix (was: Untriaged)
Closing this. We are pretty firmly rooted now in grow-as-we-serialize for C++ bindings, as it didn't have any noticeable performance impact and it substantially simplified type-mapping traits

Sign in to add a comment