[jira] [Updated] (HBASE-28485) Re-use ZstdDecompressCtx/ZstdCompressCtx for performance
[ https://issues.apache.org/jira/browse/HBASE-28485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Beaudreault updated HBASE-28485: -- Fix Version/s: (was: 4.0.0-alpha-1) > Re-use ZstdDecompressCtx/ZstdCompressCtx for performance > > > Key: HBASE-28485 > URL: https://issues.apache.org/jira/browse/HBASE-28485 > Project: HBase > Issue Type: Improvement >Reporter: Charles Connell >Assignee: Charles Connell >Priority: Major > Labels: pull-request-available > Fix For: 2.6.0, 3.0.0-beta-2, 2.5.9 > > Attachments: async-prof-flamegraph-cpu_event-1712150670836-cpu.html, > async-prof-pid-1324144-cpu-1.html > > > The zstd documentation > [recommends|https://facebook.github.io/zstd/zstd_manual.html#Chapter4] > re-using context objects when possible, because their creation has some > expense. They can be more cheaply reset than re-created. In > {{ZstdDecompressor}} and {{{}ZstdCompressor{}}}, we create a new context > object for every call to {{decompress()}} and {{{}compress(){}}}. In CPU > profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} > can sometimes represent 10-25% of the time spent in zstd decompression, which > itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance > penalty won't lead to any massive performance boost, but is a nice little win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-28485) Re-use ZstdDecompressCtx/ZstdCompressCtx for performance
[ https://issues.apache.org/jira/browse/HBASE-28485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Beaudreault updated HBASE-28485: -- Fix Version/s: 2.6.0 (was: 2.7.0) (was: 2.6.1) > Re-use ZstdDecompressCtx/ZstdCompressCtx for performance > > > Key: HBASE-28485 > URL: https://issues.apache.org/jira/browse/HBASE-28485 > Project: HBase > Issue Type: Improvement >Reporter: Charles Connell >Assignee: Charles Connell >Priority: Major > Labels: pull-request-available > Fix For: 2.6.0, 4.0.0-alpha-1, 3.0.0-beta-2, 2.5.9 > > Attachments: async-prof-flamegraph-cpu_event-1712150670836-cpu.html, > async-prof-pid-1324144-cpu-1.html > > > The zstd documentation > [recommends|https://facebook.github.io/zstd/zstd_manual.html#Chapter4] > re-using context objects when possible, because their creation has some > expense. They can be more cheaply reset than re-created. In > {{ZstdDecompressor}} and {{{}ZstdCompressor{}}}, we create a new context > object for every call to {{decompress()}} and {{{}compress(){}}}. In CPU > profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} > can sometimes represent 10-25% of the time spent in zstd decompression, which > itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance > penalty won't lead to any massive performance boost, but is a nice little win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-28485) Re-use ZstdDecompressCtx/ZstdCompressCtx for performance
[ https://issues.apache.org/jira/browse/HBASE-28485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated HBASE-28485: - Resolution: Fixed Status: Resolved (was: Patch Available) Commit applied to branch-2.5+. Thanks [~charlesconnell] for the contribution and [~apurtell] for the review! > Re-use ZstdDecompressCtx/ZstdCompressCtx for performance > > > Key: HBASE-28485 > URL: https://issues.apache.org/jira/browse/HBASE-28485 > Project: HBase > Issue Type: Improvement >Reporter: Charles Connell >Assignee: Charles Connell >Priority: Major > Labels: pull-request-available > Fix For: 4.0.0-alpha-1, 2.7.0, 3.0.0-beta-2, 2.6.1, 2.5.9 > > Attachments: async-prof-flamegraph-cpu_event-1712150670836-cpu.html, > async-prof-pid-1324144-cpu-1.html > > > The zstd documentation > [recommends|https://facebook.github.io/zstd/zstd_manual.html#Chapter4] > re-using context objects when possible, because their creation has some > expense. They can be more cheaply reset than re-created. In > {{ZstdDecompressor}} and {{{}ZstdCompressor{}}}, we create a new context > object for every call to {{decompress()}} and {{{}compress(){}}}. In CPU > profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} > can sometimes represent 10-25% of the time spent in zstd decompression, which > itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance > penalty won't lead to any massive performance boost, but is a nice little win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-28485) Re-use ZstdDecompressCtx/ZstdCompressCtx for performance
[ https://issues.apache.org/jira/browse/HBASE-28485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated HBASE-28485: - Fix Version/s: 2.7.0 3.0.0-beta-2 2.6.1 2.5.9 > Re-use ZstdDecompressCtx/ZstdCompressCtx for performance > > > Key: HBASE-28485 > URL: https://issues.apache.org/jira/browse/HBASE-28485 > Project: HBase > Issue Type: Improvement >Reporter: Charles Connell >Assignee: Charles Connell >Priority: Major > Labels: pull-request-available > Fix For: 4.0.0-alpha-1, 2.7.0, 3.0.0-beta-2, 2.6.1, 2.5.9 > > Attachments: async-prof-flamegraph-cpu_event-1712150670836-cpu.html, > async-prof-pid-1324144-cpu-1.html > > > The zstd documentation > [recommends|https://facebook.github.io/zstd/zstd_manual.html#Chapter4] > re-using context objects when possible, because their creation has some > expense. They can be more cheaply reset than re-created. In > {{ZstdDecompressor}} and {{{}ZstdCompressor{}}}, we create a new context > object for every call to {{decompress()}} and {{{}compress(){}}}. In CPU > profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} > can sometimes represent 10-25% of the time spent in zstd decompression, which > itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance > penalty won't lead to any massive performance boost, but is a nice little win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-28485) Re-use ZstdDecompressCtx/ZstdCompressCtx for performance
[ https://issues.apache.org/jira/browse/HBASE-28485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated HBASE-28485: - Fix Version/s: 4.0.0-alpha-1 > Re-use ZstdDecompressCtx/ZstdCompressCtx for performance > > > Key: HBASE-28485 > URL: https://issues.apache.org/jira/browse/HBASE-28485 > Project: HBase > Issue Type: Improvement >Reporter: Charles Connell >Assignee: Charles Connell >Priority: Major > Labels: pull-request-available > Fix For: 4.0.0-alpha-1 > > Attachments: async-prof-flamegraph-cpu_event-1712150670836-cpu.html, > async-prof-pid-1324144-cpu-1.html > > > The zstd documentation > [recommends|https://facebook.github.io/zstd/zstd_manual.html#Chapter4] > re-using context objects when possible, because their creation has some > expense. They can be more cheaply reset than re-created. In > {{ZstdDecompressor}} and {{{}ZstdCompressor{}}}, we create a new context > object for every call to {{decompress()}} and {{{}compress(){}}}. In CPU > profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} > can sometimes represent 10-25% of the time spent in zstd decompression, which > itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance > penalty won't lead to any massive performance boost, but is a nice little win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-28485) Re-use ZstdDecompressCtx/ZstdCompressCtx for performance
[ https://issues.apache.org/jira/browse/HBASE-28485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Connell updated HBASE-28485: Status: Patch Available (was: Open) > Re-use ZstdDecompressCtx/ZstdCompressCtx for performance > > > Key: HBASE-28485 > URL: https://issues.apache.org/jira/browse/HBASE-28485 > Project: HBase > Issue Type: Improvement >Reporter: Charles Connell >Assignee: Charles Connell >Priority: Major > Labels: pull-request-available > Attachments: async-prof-flamegraph-cpu_event-1712150670836-cpu.html, > async-prof-pid-1324144-cpu-1.html > > > The zstd documentation > [recommends|https://facebook.github.io/zstd/zstd_manual.html#Chapter4] > re-using context objects when possible, because their creation has some > expense. They can be more cheaply reset than re-created. In > {{ZstdDecompressor}} and {{{}ZstdCompressor{}}}, we create a new context > object for every call to {{decompress()}} and {{{}compress(){}}}. In CPU > profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} > can sometimes represent 10-25% of the time spent in zstd decompression, which > itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance > penalty won't lead to any massive performance boost, but is a nice little win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-28485) Re-use ZstdDecompressCtx/ZstdCompressCtx for performance
[ https://issues.apache.org/jira/browse/HBASE-28485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Connell updated HBASE-28485: Description: The zstd documentation [recommends|https://facebook.github.io/zstd/zstd_manual.html#Chapter4] re-using context objects when possible, because their creation has some expense. They can be more cheaply reset than re-created. In {{ZstdDecompressor}} and {{{}ZstdCompressor{}}}, we create a new context object for every call to {{decompress()}} and {{{}compress(){}}}. In CPU profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} can sometimes represent 10-25% of the time spent in zstd decompression, which itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance penalty won't lead to any massive performance boost, but is a nice little win. (was: The zstd documentation recommends re-using context objects when possible, because their creation has some expense. They can be more cheaply reset than re-created. In {{ZstdDecompressor}} and {{ZstdCompressor}}, we create a new context object for every call to {{decompress()}} and {{compress()}}. In CPU profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} can sometimes represent 10-25% of the time spent in zstd decompression, which itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance penalty won't lead to any massive performance boost, but is a nice little win.) > Re-use ZstdDecompressCtx/ZstdCompressCtx for performance > > > Key: HBASE-28485 > URL: https://issues.apache.org/jira/browse/HBASE-28485 > Project: HBase > Issue Type: Improvement >Reporter: Charles Connell >Assignee: Charles Connell >Priority: Major > Labels: pull-request-available > Attachments: async-prof-flamegraph-cpu_event-1712150670836-cpu.html, > async-prof-pid-1324144-cpu-1.html > > > The zstd documentation > [recommends|https://facebook.github.io/zstd/zstd_manual.html#Chapter4] > re-using context objects when possible, because their creation has some > expense. They can be more cheaply reset than re-created. In > {{ZstdDecompressor}} and {{{}ZstdCompressor{}}}, we create a new context > object for every call to {{decompress()}} and {{{}compress(){}}}. In CPU > profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} > can sometimes represent 10-25% of the time spent in zstd decompression, which > itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance > penalty won't lead to any massive performance boost, but is a nice little win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-28485) Re-use ZstdDecompressCtx/ZstdCompressCtx for performance
[ https://issues.apache.org/jira/browse/HBASE-28485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated HBASE-28485: --- Labels: pull-request-available (was: ) > Re-use ZstdDecompressCtx/ZstdCompressCtx for performance > > > Key: HBASE-28485 > URL: https://issues.apache.org/jira/browse/HBASE-28485 > Project: HBase > Issue Type: Improvement >Reporter: Charles Connell >Assignee: Charles Connell >Priority: Major > Labels: pull-request-available > Attachments: async-prof-flamegraph-cpu_event-1712150670836-cpu.html, > async-prof-pid-1324144-cpu-1.html > > > The zstd documentation recommends re-using context objects when possible, > because their creation has some expense. They can be more cheaply reset than > re-created. In {{ZstdDecompressor}} and {{ZstdCompressor}}, we create a new > context object for every call to {{decompress()}} and {{compress()}}. In CPU > profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} > can sometimes represent 10-25% of the time spent in zstd decompression, which > itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance > penalty won't lead to any massive performance boost, but is a nice little win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-28485) Re-use ZstdDecompressCtx/ZstdCompressCtx for performance
[ https://issues.apache.org/jira/browse/HBASE-28485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Connell updated HBASE-28485: Description: The zstd documentation recommends re-using context objects when possible, because their creation has some expense. They can be more cheaply reset than re-created. In {{ZstdDecompressor}} and {{ZstdCompressor}}, we create a new context object for every call to {{decompress()}} and {{compress()}}. In CPU profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} can sometimes represent 10-25% of the time spent in zstd decompression, which itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance penalty won't lead to any massive performance boost, but is a nice little win. (was: The zstd documentation recommends re-using context objects when possible, because their creation has some expense. They can be more cheaply reset than re-created. In ZstdDecompressor and ZstdCompressor, we create a new context object for every call to decompress() and compress(). In CPU profiles I've taken at my company, the constructor of ZstdDecompressCtx can sometimes represent 10-25% of the time spent in zstd decompression, which itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance penalty won't lead to any massive performance boost, but is a nice little win.) > Re-use ZstdDecompressCtx/ZstdCompressCtx for performance > > > Key: HBASE-28485 > URL: https://issues.apache.org/jira/browse/HBASE-28485 > Project: HBase > Issue Type: Improvement >Reporter: Charles Connell >Assignee: Charles Connell >Priority: Major > Attachments: async-prof-flamegraph-cpu_event-1712150670836-cpu.html, > async-prof-pid-1324144-cpu-1.html > > > The zstd documentation recommends re-using context objects when possible, > because their creation has some expense. They can be more cheaply reset than > re-created. In {{ZstdDecompressor}} and {{ZstdCompressor}}, we create a new > context object for every call to {{decompress()}} and {{compress()}}. In CPU > profiles I've taken at my company, the constructor of {{ZstdDecompressCtx}} > can sometimes represent 10-25% of the time spent in zstd decompression, which > itself is 5-10% of a RegionServer's total CPU time. Avoiding this performance > penalty won't lead to any massive performance boost, but is a nice little win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-28485) Re-use ZstdDecompressCtx/ZstdCompressCtx for performance
[ https://issues.apache.org/jira/browse/HBASE-28485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Connell updated HBASE-28485: Attachment: async-prof-flamegraph-cpu_event-1712150670836-cpu.html > Re-use ZstdDecompressCtx/ZstdCompressCtx for performance > > > Key: HBASE-28485 > URL: https://issues.apache.org/jira/browse/HBASE-28485 > Project: HBase > Issue Type: Improvement >Reporter: Charles Connell >Assignee: Charles Connell >Priority: Major > Attachments: async-prof-flamegraph-cpu_event-1712150670836-cpu.html, > async-prof-pid-1324144-cpu-1.html > > > The zstd documentation recommends re-using context objects when possible, > because their creation has some expense. They can be more cheaply reset than > re-created. In ZstdDecompressor and ZstdCompressor, we create a new context > object for every call to decompress() and compress(). In CPU profiles I've > taken at my company, the constructor of ZstdDecompressCtx can sometimes > represent 10-25% of the time spent in zstd decompression, which itself is > 5-10% of a RegionServer's total CPU time. Avoiding this performance penalty > won't lead to any massive performance boost, but is a nice little win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-28485) Re-use ZstdDecompressCtx/ZstdCompressCtx for performance
[ https://issues.apache.org/jira/browse/HBASE-28485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Connell updated HBASE-28485: Attachment: async-prof-pid-1324144-cpu-1.html > Re-use ZstdDecompressCtx/ZstdCompressCtx for performance > > > Key: HBASE-28485 > URL: https://issues.apache.org/jira/browse/HBASE-28485 > Project: HBase > Issue Type: Improvement >Reporter: Charles Connell >Assignee: Charles Connell >Priority: Major > Attachments: async-prof-pid-1324144-cpu-1.html > > > The zstd documentation recommends re-using context objects when possible, > because their creation has some expense. They can be more cheaply reset than > re-created. In ZstdDecompressor and ZstdCompressor, we create a new context > object for every call to decompress() and compress(). In CPU profiles I've > taken at my company, the constructor of ZstdDecompressCtx can sometimes > represent 10-25% of the time spent in zstd decompression, which itself is > 5-10% of a RegionServer's total CPU time. Avoiding this performance penalty > won't lead to any massive performance boost, but is a nice little win. -- This message was sent by Atlassian Jira (v8.20.10#820010)