Re: [Monotone-devel] Netsync performance improvement patch

[Petr Ovtchenkov]

On Monday 15 August 2005 12:36, Eric Anderson wrote:

> The main problem as I saw it with a non-contigous implementation was
> that it would be more complex than the contigous one, and that
> complexity would only give a benefit if the non-contigous structure
> was pushed much further into the code.  Examples of complexity: []
> now has to step through the list, decrementing the offset as
> appropriate, substr() has to manually construct the return string by
> copying bit by bit into the output string.
>
> Netcmd::read extracts the payload as a contigous string, which would
> end the benefit of storing the network data in a non-contigous manner.
> The benefit could be extended if the payload was represented as a
> reference to the non-contigous structure, and any conversion to a
> contigous structure was delayed.  However, this delay would require
> reference counting on the non-contigous structure so that it could be
> properly shared.
>
> In the long term, using a non-contigous data-structure to represent
> "strings" throughout the code is probably the best way to structurally
> reduce the memory usage, and could result in a performance boost if the
> lack of fast random access is taken into account.

Well, there is STLport, where strings are contiguous (+ short strings
optimization available). [http://www.stlport.org]; you can see comparison
of GNU and STLport strings implementations (really both ones has
one ancestor) here: http://complement.sourceforge.net/compare.pdf.

Bests,

  - ptr