You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by "Sijie Guo (JIRA)" <ji...@apache.org> on 2017/05/25 03:34:04 UTC

[jira] [Created] (BOOKKEEPER-1075) BK LedgerMetadata: more memory-efficient parsing of configs

Sijie Guo created BOOKKEEPER-1075:
-------------------------------------

             Summary: BK LedgerMetadata: more memory-efficient parsing of configs
                 Key: BOOKKEEPER-1075
                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-1075
             Project: Bookkeeper
          Issue Type: Bug
          Components: bookkeeper-client
            Reporter: Sijie Guo
            Assignee: Leigh Stewart
             Fix For: 4.5.0


Looking at the most prevalent client-side memory allocations, I noticed that we allocate 4KB every time we open a ledger. This is caused by allocating a 4KB buffer (in TextFormat.toStringBuilder) to account for the maximum possible Protobufs message, which is unnecessary in our case: we know the exact size of the metadata ( << 500 B) and don't need to allocate more.
    TextFormat.merge(Readable, Message.Builder) is the current method we use. This changes to use TextFormat.merge(CharSequence, Message.Builder), which avoids the extra 4K allocation conversion + an extra StringBuilder.

It is the contribution from Alex Yarmula

{quote}
commit 9d9d7dd26235a9beda4421b7bed750fea1789076
Author: Alex Yarmula <ak...@twitter.com>
Date:   Wed Sep 23 05:57:30 2015 -0700

    BK LedgerMetadata: more memory-efficient parsing of configs

    Looking at the most prevalent client-side memory allocations, I noticed that we allocate 4KB every time we open a ledger. This is caused by allocating a 4KB buffer (in TextFormat.toStringBuilder) to account for the maximum possible Protobufs message, which is unnecessary in our case: we know the exact size of the metadata ( << 500 B) and don't need to allocate more.
    TextFormat.merge(Readable, Message.Builder) is the current method we use. This changes to use TextFormat.merge(CharSequence, Message.Builder), which avoids the extra 4K allocation conversion + an extra StringBuilder.
    RB_ID=745700
{quote}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)