Since there hasn't been any release of Geode native are you using what is on 
development branch or a specific commit? 

If you don't intend to do any server side queries or function execution you 
could write your own custom serialization optimized for your data structure. 

PDX on C++ is mature but there is inherent performance cost of converting data 
structures to and from serialized forms in a generic cross platform way. 

I assume you're using a profiling tool. Can you share the entire output from 
that tool?

-Jake


Sent from my iPhone

> On Jun 14, 2017, at 3:12 AM, Evaristo José Camarero 
> <[email protected]> wrote:
> 
> Hi there,
>  
> We are using Apache Geode 1.1 as DB backend and a C++ application as client 
> that is using Geode-native pre-release (and using PDX serialization), and the 
> summary is that we are experience that PDX deserialization is taking most of 
> the CPU in our C++ application.
>  
> When benchmarking the application we see the following (in a 12 cores 
> machine):
> - Geode CPU usage is really low (let's say 40%)
> - Client app CPU usage is really (let's say 700%)
>  
> If we push further the benchmark the latencies are simply too high
>  
> The objects that we store looks like:
>           CacheableKeyPtr key;
>     char *a;
>     bool bdistributedEntry;
>     CacheableStringPtr c;
>     CacheableHashMapPtr attributesMap;
>     // children are kept only for distributed entries
>     CacheableLinkedHashSetPtr d;
> 
> 
> 
> 
> This method consumes most of the CPU:
> CacheablePtr attributes;
>     instance->getField("attributes", attributes);
> 
> 
> 
> 
> I have some doubts about:
> - Is C++ PDX serialization mature and performant? I have read some benchmarks 
> about Java's library but I was not able to find information about the C++ 
> library.
> - Is there any of modelling guidelines that could alleviate the serialization 
> performance issue? We have started with a design in which classes are 
> designed for simplicity without consider PDX serialization performance aspect
> 
> 
> Thx in advance,
> 
> 
> Evaristo

Reply via email to