[
https://issues.apache.org/jira/browse/HDFS-10656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15665493#comment-15665493
]
Xiao Chen edited comment on HDFS-10656 at 11/15/16 4:17 PM:
------------------------------------------------------------
Thank you for the nice optimization [~daryn]!
Sorry for posting my late questions here:
- -It seems the new check on range doesn't cover the scenario that {{length}} <
0. So {{length < 0 && offset + length >=0}} would be a valid input. Should we
worry about this?- Edit: sorry false alarm, my bad.
- It seems the old behavior is to always return {{""}} if the byte array is
0-length, without any input validation on {{offset}}/{{length}}. New behavior
will throw {{IndexOutOfBoundsException}} from the precondition check.
I'm only asking from a code review perspective. And I guess this is okay since
{{DFSUtil}} is private? Not sure why the old behavior is as such.
was (Author: xiaochen):
Thank you for the nice optimization [~daryn]!
Sorry for posting my late questions here:
- It seems the new check on range doesn't cover the scenario that {{length}} <
0. So {{length < 0 && offset + length >=0}} would be a valid input. Should we
worry about this?
- It seems the old behavior is to always return {{""}} if the byte array is
0-length, without any input validation on {{offset}}/{{length}}. New behavior
will throw {{IndexOutOfBoundsException}} from the precondition check.
I'm only asking from a code review perspective. And I guess this is okay since
{{DFSUtil}} is private? Not sure why the old behavior is as such.
> Optimize conversion of byte arrays back to path string
> ------------------------------------------------------
>
> Key: HDFS-10656
> URL: https://issues.apache.org/jira/browse/HDFS-10656
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Fix For: 2.8.0, 2.9.0, 2.7.4, 3.0.0-alpha1
>
> Attachments: HDFS-10656.patch
>
>
> {{DFSUtil.byteArray2PathString}} generates excessive object allocation.
> # each byte array is encoded to a string (copy)
> # string appended to a builder which extracts the chars from the intermediate
> string (copy) and adds to its own char array
> # builder's char array is re-alloced if over 16 chars (copy)
> # builder's toString creates another string (copy)
> Instead of allocating all these objects and performing multiple byte/char
> encoding/decoding conversions, the byte array can be built in-place with a
> single final conversion to a string.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
