Remove redundant reading and writing of data about SharedBuffer.

Remove redundant reading and writing of data about SharedBuffer.

When decoding an image, the encoding data should be copied from SharedBuffer to SkRWBuffer,
and after the data is accepted completed, webcore thread can access the encoded data only
by generating SharedBuffer from SkRWBuffer. Obviously, there is redundant reading and writing
of data in the above process.

Depending on whether the vectors' capacity needs to be expanded, SharedBuffer can be divided
into several steps. In step, single thread writing and multi-threaded reading are safe. So only
in the step switch, synchronization should be make. This cost is light enough. Moreover, the
existing ROBufferSegmentReader also need to add a wide range of lock when reading.

In addition, SharedBuffer supports random access, while ROBufferSegmentReader only supports
forward or backward access by segment.

design doc: https://docs.google.com/document/d/12nBhu8HKjxnuUrfmIhXfTSdPcV1ieCKHmzaAvyOHGM0/edit

benchmark results:
https://docs.google.com/spreadsheets/d/1ThAJV33yZJMx9tp2CLKZ5tmkomXLJiBM4mfqFFOK4iQ/edit#gid=0

BUG=727995

[Haipeng Liu, 2017-05-31 04:34:06]

Description was changed from

==========
Remove redundant reading and writing of data about SharedBuffer.

When decoding an image, the encoding data should be copied from SharedBuffer to
SkRWBuffer,
and after the data is accepted completed, webcore thread can access the encoded
data only
by generating SharedBuffer from SkRWBuffer. Obviously, there is redundant
reading and writing
of data in the above process.

Depending on whether the vectors' capacity needs to be expanded, SharedBuffer
can be divided
into several steps. In step, single thread writing and multi-threaded reading
are safe. So only
in the step switch, synchronization should be make. This cost is light enough.
Moreover, the
existing ROBufferSegmentReader also need to add a wide range of lock when
reading.

In addition, SharedBuffer supports random access, while ROBufferSegmentReader
only supports
forward or backward access by segment.

BUG=727995
==========

to

==========
Remove redundant reading and writing of data about SharedBuffer.

When decoding an image, the encoding data should be copied from SharedBuffer to
SkRWBuffer,
and after the data is accepted completed, webcore thread can access the encoded
data only
by generating SharedBuffer from SkRWBuffer. Obviously, there is redundant
reading and writing
of data in the above process.

Depending on whether the vectors' capacity needs to be expanded, SharedBuffer
can be divided
into several steps. In step, single thread writing and multi-threaded reading
are safe. So only
in the step switch, synchronization should be make. This cost is light enough.
Moreover, the
existing ROBufferSegmentReader also need to add a wide range of lock when
reading.

In addition, SharedBuffer supports random access, while ROBufferSegmentReader
only supports
forward or backward access by segment.

BUG=727995
==========

[Haipeng Liu, 2017-05-31 04:34:07]

hpeterliu@tencent.com changed reviewers:
+ fmalita@chromium.org, haraken@chromium.org, hiroshige@chromium.org,
mkwst@chromium.org, scroggo@chromium.org, tasak@google.com

[Haipeng Liu, 2017-05-31 04:37:41]

The CQ bit was checked by hpeterliu@tencent.com

[Haipeng Liu, 2017-05-31 04:37:42]

The CQ bit was unchecked by hpeterliu@tencent.com

[hiroshige, 2017-05-31 08:55:06]

The CQ bit was checked by hiroshige@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-31 08:55:27]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[hiroshige, 2017-05-31 08:56:02]

hiroshige@chromium.org changed reviewers:
+ hajimehoshi@chromium.org

[hiroshige, 2017-05-31 08:56:03]

+hajimehoshi@.

[commit-bot: I haz the power, 2017-05-31 09:07:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-31 09:07:04]

Dry run: Try jobs failed on following builders:
  linux_chromium_headless_rel on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[hiroshige, 2017-05-31 09:55:05]

The CQ bit was checked by hiroshige@chromium.org to run a CQ dry run

[Haipeng Liu, 2017-05-31 09:55:08]

The CQ bit was checked by hpeterliu@tencent.com to run a CQ dry run

[commit-bot: I haz the power, 2017-05-31 09:55:11]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-31 09:55:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-31 09:55:15]

Dry run: No L-G-T-M from a valid reviewer yet.
CQ run can only be started once the patch has received an L-G-T-M from a full
committer.
Even if an L-G-T-M may have been provided, it was from a non-committer,_not_ a
full super star committer.
Committers are members of the group "project-chromium-committers".
Note that this has nothing to do with OWNERS files.

[Haipeng Liu, 2017-05-31 10:05:14]

On 2017/05/31 08:56:03, hiroshige wrote:
> +hajimehoshi@.

I have fixed the compiling error caused by carelessness. Can you dry CQ run for
me? Thanks!

[hajimehoshi, 2017-05-31 10:08:24]

The CQ bit was checked by hajimehoshi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-31 10:08:35]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[hajimehoshi, 2017-05-31 10:09:44]

On 2017/05/31 10:05:14, hpeterliu wrote:
> On 2017/05/31 08:56:03, hiroshige wrote:
> > +hajimehoshi@.
> 
> I have fixed the compiling error caused by carelessness. Can you dry CQ run
for
> me? Thanks!

Done.

Have you checked if performance regression happened or not?

As for the design, I'd like to ask skia people's opinion.

[commit-bot: I haz the power, 2017-05-31 10:20:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-31 10:20:59]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Haipeng Liu, 2017-05-31 10:36:19]

On 2017/05/31 10:09:44, hajimehoshi wrote:
> On 2017/05/31 10:05:14, hpeterliu wrote:
> > On 2017/05/31 08:56:03, hiroshige wrote:
> > > +hajimehoshi@.
> > 
> > I have fixed the compiling error caused by carelessness. Can you dry CQ run
> for
> > me? Thanks!
> 
> Done.
> 
> Have you checked if performance regression happened or not?
> 
> As for the design, I'd like to ask skia people's opinion.


I have been thinking about how to measure the performance changes caused by this
change. 
A performance report will be given in recent days as expected.

[Haipeng Liu, 2017-05-31 10:59:16]

Patchset #1 (id:1) has been deleted

[Haipeng Liu, 2017-05-31 10:59:41]

Patchset #1 (id:20001) has been deleted

[Haipeng Liu, 2017-05-31 11:30:57]

On 2017/05/31 10:09:44, hajimehoshi wrote:
> On 2017/05/31 10:05:14, hpeterliu wrote:
> > On 2017/05/31 08:56:03, hiroshige wrote:
> > > +hajimehoshi@.
> > 
> > I have fixed the compiling error caused by carelessness. Can you dry CQ run
> for
> > me? Thanks!
> 
> Done.
> 
> Have you checked if performance regression happened or not?
> 
> As for the design, I'd like to ask skia people's opinion.


Unfortunately, another compilation error has occurred. My local chromium
compilation system has a problem: only changing the header file does not trigger
compilation, which leads to the above compilation error. This time I deleted all
the target files under the platform directory and make the compilation system
recompile, during the compilation no compilation problems was reported. Indeed,
I have compiled and validated the chromium executable several times before this
CL. 


If you can re-trigger the CQ run, I will be very grateful.

[hajimehoshi, 2017-05-31 11:34:44]

The CQ bit was checked by hajimehoshi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-31 11:34:58]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-31 11:56:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-31 11:56:32]

Dry run: Try jobs failed on following builders:
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)

[Haipeng Liu, 2017-05-31 12:14:49]

On 2017/05/31 11:30:57, hpeterliu wrote:
> On 2017/05/31 10:09:44, hajimehoshi wrote:
> > On 2017/05/31 10:05:14, hpeterliu wrote:
> > > On 2017/05/31 08:56:03, hiroshige wrote:
> > > > +hajimehoshi@.
> > > 
> > > I have fixed the compiling error caused by carelessness. Can you dry CQ
run
> > for
> > > me? Thanks!
> > 
> > Done.
> > 
> > Have you checked if performance regression happened or not?
> > 
> > As for the design, I'd like to ask skia people's opinion.
> 
> 
> Unfortunately, another compilation error has occurred. My local chromium
> compilation system has a problem: only changing the header file does not
trigger
> compilation, which leads to the above compilation error. This time I deleted
all
> the target files under the platform directory and make the compilation system
> recompile, during the compilation no compilation problems was reported.
Indeed,
> I have compiled and validated the chromium executable several times before
this
> CL. 
> 
> 
> If you can re-trigger the CQ run, I will be very grateful.

fix comple error. My local compilation configuration may vary from CQ.

[hiroshige, 2017-05-31 12:44:42]

The CQ bit was checked by hiroshige@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-31 12:44:52]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-31 13:16:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-31 13:16:21]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[f(malita), 2017-05-31 15:06:27]

fmalita@chromium.org changed reviewers:
+ pkasting@chromium.org

[f(malita), 2017-05-31 15:08:28]

Before diving into implementation details, I'd like to understand the motivation
and trade-offs.

> webcore thread can access the encoded data only by generating SharedBuffer
> from SkRWBuffer. Obviously, there is redundant reading and writing
> of data in the above process.

The current approach is optimized for the common rasterization/decoding path --
what are the cases where main thread access to encoded data is performance
sensitive?

Do you have some benchmark numbers demonstrating progress?

Is this progress worth the additional complexity?

If we make SharedBuffer thread-safe, I would expect us to also remove a bunch of
the existing data shuffling machinery, effectively reducing complexity.  That
doesn't seem to be the case with this CL - how come?

Have you considered backing SharedBuffer with a SkRWBuffer instead of
introducing new buffer types?  At a quick glance it seems to provide the right
semantics (thread-safe, lock-less readers).

[Haipeng Liu, 2017-06-01 09:32:56]

On 2017/05/31 15:08:28, f(malita) wrote:
> Before diving into implementation details, I'd like to understand the
motivation
> and trade-offs.
I make these changes for removing redundant reading and writing of data about
SharedBuffer, and simultaneously maintaining the performance and efficiency of
the existing code. 
 
> > webcore thread can access the encoded data only by generating SharedBuffer
> > from SkRWBuffer. Obviously, there is redundant reading and writing
> > of data in the above process.
> 
> The current approach is optimized for the common rasterization/decoding path
--
> what are the cases where main thread access to encoded data is performance
> sensitive?
The current approach use SkRWBuffer to eliminate copies of encoded image data
and remove a mutex lock to reach a significant optimization of performance, but
there was still a duplication of encoded data. In
https://codereview.chromium.org/2054643003, the duplication was removed, but
left a redundant reading and writing. And in this CL, I try to remove the
redundant reading and writing by minor modifications on SharedBuffer which is
divided into several steps. Only when the step switch, a lock is needed. It
rarely occurs, and contains only 2,3 lines of statements. I think the impact of
this lock on the performance will be very small and i am even thinking about how
to remove this lock. I will do some benchmark test in recent days.
 
> Do you have some benchmark numbers demonstrating progress?
> 
> Is this progress worth the additional complexity?
> 
> If we make SharedBuffer thread-safe, I would expect us to also remove a bunch
of
> the existing data shuffling machinery, effectively reducing complexity.  That
> doesn't seem to be the case with this CL - how come?
> 
> Have you considered backing SharedBuffer with a SkRWBuffer instead of
> introducing new buffer types?  At a quick glance it seems to provide the right
> semantics (thread-safe, lock-less readers).

Some webcore users call SharedBuffer::Data method, and for historical reasons,
SharedBuffer has more affinity on webcore code than SkRWBuffer. In calling
GetSomeData method which is often called in image decoding, the SharedBuffer can
behave the same as the SkRWBuffer in performance. for thus reasons, I tried to
make the SharedBuffer thread safe by little modifications.

[Haipeng Liu, 2017-06-03 11:29:40]

Patchset #3 (id:80001) has been deleted

[Haipeng Liu, 2017-06-03 14:29:02]

The CQ bit was checked by hpeterliu@tencent.com to run a CQ dry run

[commit-bot: I haz the power, 2017-06-03 14:29:17]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-03 14:29:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-03 14:29:21]

Dry run: No L-G-T-M from a valid reviewer yet.
CQ run can only be started once the patch has received an L-G-T-M from a full
committer.
Even if an L-G-T-M may have been provided, it was from a non-committer,_not_ a
full super star committer.
Committers are members of the group "project-chromium-committers".
Note that this has nothing to do with OWNERS files.

[Haipeng Liu, 2017-06-05 10:07:00]

Patchset #3 (id:100001) has been deleted

[Haipeng Liu, 2017-06-05 10:23:04]

use atomic operations instead of mutex lock to synchronize steps.

may somebody can dry CQ run for me?

I have written a doc about this change
https://docs.google.com/document/d/12nBhu8HKjxnuUrfmIhXfTSdPcV1ieCKHmzaAvyOHG....
may somebody can tell me the feasibility of this path. Grateful!

[Haipeng Liu, 2017-06-05 10:27:05]

Description was changed from

==========
Remove redundant reading and writing of data about SharedBuffer.

When decoding an image, the encoding data should be copied from SharedBuffer to
SkRWBuffer,
and after the data is accepted completed, webcore thread can access the encoded
data only
by generating SharedBuffer from SkRWBuffer. Obviously, there is redundant
reading and writing
of data in the above process.

Depending on whether the vectors' capacity needs to be expanded, SharedBuffer
can be divided
into several steps. In step, single thread writing and multi-threaded reading
are safe. So only
in the step switch, synchronization should be make. This cost is light enough.
Moreover, the
existing ROBufferSegmentReader also need to add a wide range of lock when
reading.

In addition, SharedBuffer supports random access, while ROBufferSegmentReader
only supports
forward or backward access by segment.

BUG=727995
==========

to

==========
Remove redundant reading and writing of data about SharedBuffer.

When decoding an image, the encoding data should be copied from SharedBuffer to
SkRWBuffer,
and after the data is accepted completed, webcore thread can access the encoded
data only
by generating SharedBuffer from SkRWBuffer. Obviously, there is redundant
reading and writing
of data in the above process.

Depending on whether the vectors' capacity needs to be expanded, SharedBuffer
can be divided
into several steps. In step, single thread writing and multi-threaded reading
are safe. So only
in the step switch, synchronization should be make. This cost is light enough.
Moreover, the
existing ROBufferSegmentReader also need to add a wide range of lock when
reading.

In addition, SharedBuffer supports random access, while ROBufferSegmentReader
only supports
forward or backward access by segment.

design doc:
https://docs.google.com/document/d/12nBhu8HKjxnuUrfmIhXfTSdPcV1ieCKHmzaAvyOHG...

BUG=727995
==========

[Haipeng Liu, 2017-06-05 12:03:01]

On 2017/05/31 15:08:28, f(malita) wrote:
> Before diving into implementation details, I'd like to understand the
motivation
> and trade-offs.
> 
> > webcore thread can access the encoded data only by generating SharedBuffer
> > from SkRWBuffer. Obviously, there is redundant reading and writing
> > of data in the above process.
> 
> The current approach is optimized for the common rasterization/decoding path
--
> what are the cases where main thread access to encoded data is performance
> sensitive?
> 
> Do you have some benchmark numbers demonstrating progress?
> 
> Is this progress worth the additional complexity?
> 
> If we make SharedBuffer thread-safe, I would expect us to also remove a bunch
of
> the existing data shuffling machinery, effectively reducing complexity.  That
> doesn't seem to be the case with this CL - how come?
> 
> Have you considered backing SharedBuffer with a SkRWBuffer instead of
> introducing new buffer types?  At a quick glance it seems to provide the right
> semantics (thread-safe, lock-less readers).

Compared to the path of backing SharedBuffer with a SkRWBuffer, this design
shows 4 advantages:
1, The existing SharedBuffer has good support for small data. Data with size
less than 4096 is stored in continuous memory, and data users can easily access
it in the form of Data (). It is undeniable that this form of access to small
data is more convenient.
2，Both SharedBuffer and SkRWBuffer store the data in multiple stages. The
difference is that SharedBuffer organizes segments in an array, and SkRWBuffer
organizes segments in a linked list. Organizing segments in an array support
random access, why not keep this additional advantage?
3, SharedBufferStep can also be handed like SkROBuffer to reading threads to
thread-safely read when the data changes. But furtherly,
SharedBuffer::TharedSafeStepper in this design can be handed to the reading
thread, and then the read thread can access the latest data through 
current SharedBufferStep obtained by TharedSafeStepper::current_step(). A
possible optimization based on this feature is to move the GIF playback to the
CC layer to reduce the large amount of communication between the blink and the
cc layer during the playback.
4, More importantly, after using the atomic operations, the contention between
the sentences is eliminated, leaving only instruction-level synchronization. So
performance can be guaranteed.

[Haipeng Liu, 2017-06-06 05:53:09]

Patchset #3 (id:120001) has been deleted

[Haipeng Liu, 2017-06-06 06:14:43]

Patchset #3 (id:130018) has been deleted

[Haipeng Liu, 2017-06-06 06:23:41]

hpeterliu@tencent.com changed reviewers:
+ noel@chromium.org, reed@google.com, urvang@chromium.org

[Haipeng Liu, 2017-06-06 08:34:37]

On 2017/05/31 10:09:44, hajimehoshi wrote:
> On 2017/05/31 10:05:14, hpeterliu wrote:
> > On 2017/05/31 08:56:03, hiroshige wrote:
> > > +hajimehoshi@.
> > 
> > I have fixed the compiling error caused by carelessness. Can you dry CQ run
> for
> > me? Thanks!
> 
> Done.
> 
> Have you checked if performance regression happened or not?
> 
> As for the design, I'd like to ask skia people's opinion.

I have remove the mutex lock and written a doc about the design. Would you can
give me some advice?

[Haipeng Liu, 2017-06-09 08:17:41]

hpeterliu@tencent.com changed reviewers:
+ bashi@chromium.org, cmumford@chromium.org
- fmalita@chromium.org, mkwst@chromium.org, noel@chromium.org,
pkasting@chromium.org, reed@google.com, tasak@google.com, urvang@chromium.org

[Haipeng Liu, 2017-06-09 08:18:14]

hpeterliu@tencent.com changed reviewers:
+ fmalita@chromium.org

[Haipeng Liu, 2017-06-15 11:52:58]

Description was changed from

==========
Remove redundant reading and writing of data about SharedBuffer.

When decoding an image, the encoding data should be copied from SharedBuffer to
SkRWBuffer,
and after the data is accepted completed, webcore thread can access the encoded
data only
by generating SharedBuffer from SkRWBuffer. Obviously, there is redundant
reading and writing
of data in the above process.

Depending on whether the vectors' capacity needs to be expanded, SharedBuffer
can be divided
into several steps. In step, single thread writing and multi-threaded reading
are safe. So only
in the step switch, synchronization should be make. This cost is light enough.
Moreover, the
existing ROBufferSegmentReader also need to add a wide range of lock when
reading.

In addition, SharedBuffer supports random access, while ROBufferSegmentReader
only supports
forward or backward access by segment.

design doc:
https://docs.google.com/document/d/12nBhu8HKjxnuUrfmIhXfTSdPcV1ieCKHmzaAvyOHG...

BUG=727995
==========

to

==========
Remove redundant reading and writing of data about SharedBuffer.

When decoding an image, the encoding data should be copied from SharedBuffer to
SkRWBuffer,
and after the data is accepted completed, webcore thread can access the encoded
data only
by generating SharedBuffer from SkRWBuffer. Obviously, there is redundant
reading and writing
of data in the above process.

Depending on whether the vectors' capacity needs to be expanded, SharedBuffer
can be divided
into several steps. In step, single thread writing and multi-threaded reading
are safe. So only
in the step switch, synchronization should be make. This cost is light enough.
Moreover, the
existing ROBufferSegmentReader also need to add a wide range of lock when
reading.

In addition, SharedBuffer supports random access, while ROBufferSegmentReader
only supports
forward or backward access by segment.

design doc:
https://docs.google.com/document/d/12nBhu8HKjxnuUrfmIhXfTSdPcV1ieCKHmzaAvyOHG...

benchmark results:
https://docs.google.com/spreadsheets/d/1ThAJV33yZJMx9tp2CLKZ5tmkomXLJiBM4mfqF...

BUG=727995
==========

[Haipeng Liu, 2017-06-15 12:03:03]

A DeferredImageDecodeBench has been added for making
Comparison of decoding performance before and after modification. According to
the results, The thread-safe SharedBuffer saves writing time, but does not
generate additional synchronization costs. So the overall performance has
improved slightly.　See details in
https://docs.google.com/spreadsheets/d/1ThAJV33yZJMx9tp2CLKZ5tmkomXLJiBM4mfqF...

[Haipeng Liu, 2017-06-15 12:13:30]

Patchset #5 (id:190001) has been deleted

[Haipeng Liu, 2017-06-15 12:24:16]

Patchset #5 (id:210001) has been deleted

[Haipeng Liu, 2017-06-21 10:13:08]

On 2017/06/15 12:03:03, Haipeng Liu wrote:
> A DeferredImageDecodeBench has been added for making
> Comparison of decoding performance before and after modification. According to
> the results, The thread-safe SharedBuffer saves writing time, but does not
> generate additional synchronization costs. So the overall performance has
> improved slightly.　See details in
>
https://docs.google.com/spreadsheets/d/1ThAJV33yZJMx9tp2CLKZ5tmkomXLJiBM4mfqF...

Would someone can make some suggestions on this issue?

[f(malita), 2017-06-22 14:37:39]

On 2017/06/21 10:13:08, Haipeng Liu wrote:
> On 2017/06/15 12:03:03, Haipeng Liu wrote:
> > A DeferredImageDecodeBench has been added for making
> > Comparison of decoding performance before and after modification. According
to
> > the results, The thread-safe SharedBuffer saves writing time, but does not
> > generate additional synchronization costs. So the overall performance has
> > improved slightly.　See details in
> >
>
https://docs.google.com/spreadsheets/d/1ThAJV33yZJMx9tp2CLKZ5tmkomXLJiBM4mfqF...
> 
> Would someone can make some suggestions on this issue?

Thank you for the benchmark, looks like we're on the right track.

A significant reason for SharedBuffer's complexity is the data-flattening API -
Data().  We are in the process of attempting to remove that, and convert
existing clients to the sequential/segment-based API:
https://bugs.chromium.org/p/chromium/issues/detail?id=728627

I expect this CL to get much simpler after we remove Data(), so I would suggest
waiting for that refactoring to land first.