Memory allocation and GC

[ebfhub]

The generated code (and support code) seems to allocate memory on use.
This is fine in many cases, but if you want to use this in certain applications, memory allocation needs to be kept to a minimum (e.g. low latency, processing market data).
With some changes, adding a reset to the builder, and returning cached builder objects, this should be achievable. On the decoding side this would also be necessary.

This has been achieved with SBE, and Jackson's CBOR (except for strings).

[dwrensha]

I agree. There's probably significant room for optimization in this direction.

Ideally we could add such optimized interfaces without making things more difficult for users who prefer having an easier-to-use interface over squeezing every drop of performance.

[paxel]

I made almost all reader and builder recyclable in my fork to avoid creating so many objects. the code looks not very Java in the end. also I didn't find the time to actually make a simple way to use my fork. but you might want to check it: https://github.com/paxel/capnproto-java David Renshaw <[email protected]> schrieb am So., 2. Feb. 2020, 15:35:

…

I agree. There's probably significant room for optimization in this direction. Ideally we could add such optimized interfaces without making things more difficult for users who prefer having an easier-to-use interface over squeezing every drop of performance. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#76?email_source=notifications&email_token=AAFLHGC7PPQIGXXQO2ZDVB3RA3K4XA5CNFSM4KOYURJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKRYH6I#issuecomment-581141497>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFLHGFONAZBN6W5OZQXN4LRA3K4XANCNFSM4KOYURJA> .