Re: svn commit: r1072302 - in /subversion/trunk: ./ subversion/include/private/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/libsvn_subr/

[Ivan Zhakov <iv...@visualsvn.com>]

On Sat, Feb 19, 2011 at 13:47,  <st...@apache.org> wrote:
> Author: stefan2
> Date: Sat Feb 19 10:47:16 2011
> New Revision: 1072302
>
> URL: http://svn.apache.org/viewvc?rev=1072302&view=rev
> Log:
> Merge all changes (r1068724, r1068739) from the
> integrate-cache-item-serialization branch.
>
> These patches introduce a very simple, limited purpose
> serialization framework and use that to switch the
> caching API from data copying to the more generally
> applicable (de-)serialization mechanism.
>
> This makes all types of caches usable with all types
> of cacheable items.
>
Hi Stefan,

Why serialize/deserialize mechanism is better than data copying
function? For me implementing dup function is much easier and better
for performance than serialize/deserialize. Is it possible to keep
both mechanism in inprocess cache?

-- 
Ivan Zhakov

Re: svn commit: r1072302 - in /subversion/trunk: ./ subversion/include/private/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/libsvn_subr/

[Stefan Fuhrmann <st...@alice-dsl.de>]

On 19.02.2011 12:12, Ivan Zhakov wrote:
> On Sat, Feb 19, 2011 at 13:47,<st...@apache.org>  wrote:
>> Author: stefan2
>> Date: Sat Feb 19 10:47:16 2011
>> New Revision: 1072302
>>
>> URL: http://svn.apache.org/viewvc?rev=1072302&view=rev
>> Log:
>> Merge all changes (r1068724, r1068739) from the
>> integrate-cache-item-serialization branch.
>>
>> These patches introduce a very simple, limited purpose
>> serialization framework and use that to switch the
>> caching API from data copying to the more generally
>> applicable (de-)serialization mechanism.
>>
>> This makes all types of caches usable with all types
>> of cacheable items.
>>
> Hi Stefan,
>
> Why serialize/deserialize mechanism is better than data copying
> function?
This is not (de)serialization as in "write / parse some ASCII text"
but more basic as in "combine everything into a single, movable
binary chunk of data".

Basically, I simply concatenate all structs (memcpy) and replace
all pointers by local offsets. This requires some state management
during serialization but saves on allocations. This makes the
serialization part about as fast as standard copy code.

De-serialization is much faster, though: Only a single, aligned
allocation and memcpy followed by straightforward pointer
fix-up is necessary. The latter is equivalent to just setting the
pointer values during ordinary copying. Hence, we save greatly
on the allocation and copying part.
> For me implementing dup function is much easier and better
> for performance than serialize/deserialize. Is it possible to keep
> both mechanism in inprocess cache?
It is possible but not beneficial. We would need to keep code
for redundant functionality around that is generally slower and
limited in its applicability as it works for cache-inprocess only.

-- Stefan^2.