resources demands for multiple ChronicalMap instances

[Felix]

I am considering usage of ChronicleMap for exchange of inter-process data. The data comes in various types - mainly java native types.
From the simplistic view it appears convenient and efficient to set a ChronicleMap  instance/object per given data type. for example:

ChronicleMap<LongValue, BooleanValue> ipcMap_Bool   = ChronicleMapBuilder .of(LongValue.class, BooleanValue.class).entries(limitBool  );
ChronicleMap<LongValue, ByteValue>    ipcMap_Byte   = ChronicleMapBuilder .of(LongValue.class, ByteValue.class)   .entries(limitByte  );
ChronicleMap<LongValue, CharValue>    ipcMap_Char   = ChronicleMapBuilder .of(LongValue.class, CharValue.class)   .entries(limitChar  );
ChronicleMap<LongValue, DoubleValue>  ipcMap_Double = ChronicleMapBuilder .of(LongValue.class, DoubleValue.class) .entries(limitDouble);
ChronicleMap<LongValue, FloatValue>   ipcMap_Float  = ChronicleMapBuilder .of(LongValue.class, FloatValue.class)  .entries(limitFloat );
ChronicleMap<LongValue, IntValue>     ipcMap_Int    = ChronicleMapBuilder .of(LongValue.class, IntValue.class)    .entries(limitInt   );
ChronicleMap<LongValue, LongValue>    ipcMap_Long   = ChronicleMapBuilder .of(LongValue.class, LongValue.class)   .entries(limitLong  );
ChronicleMap<LongValue, ShortValue>   ipcMap_Short  = ChronicleMapBuilder .of(LongValue.class, ShortValue.class)  .entries(limitShort );
ChronicleMap<LongValue, StringValue>  ipcMap_String = ChronicleMapBuilder .of(LongValue.class, StringValue.class) .entries(limitString);
ChronicleMap<LongValue, Date>         ipcMap_Date   = ChronicleMapBuilder .of(LongValue.class, Date.class)        .entries(limitDate  );

I am wondering what demands this arrangement would have on the system (considered usage is for generic PC / workstation, speed of updates not critical). Is ChronicleMap fairly light component - many objects are easily handled? Are there lots of threads fired in the background, etc. What better approach would there be if this idea proves to be and overkill with too many instances of ChronicleMap? Thank you.

[Roman Leventov]

A Chronicle Map with small keys/values configured to store just one entry takes about 8 KB: https://github.com/OpenHFT/Chronicle-Map/blob/master/src/test/resources/chronicle-map-3-8-file.dat

You can calculate disk footprint for one Map as 8 KB + numberOfEntries * (keySize + valueSize + 10-20 bytes),approximately.

Each Chronicle Map object uses some own thread-local assets, which I didn't measure, but my estimate is a few KBs. Those objects are created in each Thread, accessing Chronicle Map, and alive until the Thread of the Chronicle Map is alive (in terms of GC).

Local Chronicle Map doesn't fire background threads now, but may start to do this in future versions. Replicated Chronicle Map fires a single background thread.

If you exchange objects in structures, e. g. not individual booleans, bytes and ints, but structures like boolean + 2 bytes + int, you should better define a value interface (https://github.com/OpenHFT/Chronicle-Values#value-interface-specification) and specify it as Chronicle Map's value, and exchange them. However if you indeed want to exchange individual primitives, Strings and Dates, a bunch of Chronicle Maps should be ok.

[Roman Leventov]

...and alive until the Thread OR the Chronicle Map is alive

[Felix]

Wow. that was a quick answer. Logical. Thank you Roman. Looks like you guys are pretty dedicated to this. That is great. I am having fun with this product and may have few more questions later. Enjoy your day an your creativity.

[Roman Leventov]

Thanks!

--
You received this message because you are subscribed to the Google Groups "Chronicle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicle+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peter Lawrey]

Hello Felix,
   In testing we have tested 1000 Chronicle Maps at once without significant overhead. All the data is kept off heap so whether you have one million or one billion entries the heap usage and GC pause times not impacted very much.

Regards, Peter.

[Felix]

That is a significant information, knowing that some number of instances can be used while not exhausting the processing power of the system. Thank you, Peter.

To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicl...@googlegroups.com.