
<!DOCTYPE html>

<html>

<head>

<title></title>

</head>

<body><div>On Wed, Apr 29, 2015, at 11:45, François Battail wrote:<br></div>

<blockquote type="cite"><div>with liprotobuf-c.so, default allocator, without assembly support: 799s<br></div>

<div>(bandwidth: 33.9 MiB/s)<br></div>

<div>with liprotobuf-c.so, sw_pool_t allocator, little assembly support: 629s<br></div>

<div>(bandwidth: 43.1 MiB/s)"<br></div>

</blockquote><div> </div>

<div>Point taken -- in future comparisons I will focus on throughput as much or more than size itself. I did notice that protobuf-c allows for customizing ProtobufCAllocator, and it's interesting to see the results of using a pool allocator. However my first reaction is that we really shouldn't need to do much dynamic allocation at all to handle OSM data. The use of dynamic allocation is a result of the general-purpose nature of Protobuf. My sense is that Protobuf is not even a particularly good fit for bulk OSM data transfer, considering the hoops that we must jump through in dense-nodes to bypass the natural mapping of one Protobuf message to one OSM entity.<br></div>

<div> </div>

<blockquote type="cite"><div>Most of the time is spent in zlib, libprotobuf-c and memory allocations.<br></div>

<div>I've addressed the last point using x86_64 assembly language and a pool<br></div>

<div>allocator. I think a rewrite of an optimized libprotobuf library would<br></div>

<div>help to gain some speed but the cost is very high (at least for my<br></div>

<div>application).<br></div>

</blockquote><div> </div>

<div>The alternative being to use a format that is not based on Protobuf at all, but only uses its variable-byte encoding scheme.<br></div>

<div> </div>

<div>Thanks for your comments!</div>

<div>Andrew</div>

<div> </div>

</body>

</html>