[
https://issues.apache.org/jira/browse/CALCITE-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17068428#comment-17068428
]
neoremind commented on CALCITE-3878:
------------------------------------
[~donnyzone] For code style, I think that is a good advice but not mandatory.
But for critical path or hot code, people should aware of that potential
overhead.
Assume we do know the exact size of a list or map (plus loading factor), if the
collection does not return or goes into deeper method, then we can tell it is
100% safe without resizing. If the collection escapes and being manipulated
again, simply let it resize because it works the same as we don't specify
initial capacity currently.
I sorry I am little sensitive to memory usage and performance, compared with IO
overhead, this is too little to talk. Fundamental framework should balance good
code and performance well, I think the change of making an initial capacity
does not disturbing too much. Personal opinion :D
> Make ArrayList creation with initial capacity when size is fixed
> ----------------------------------------------------------------
>
> Key: CALCITE-3878
> URL: https://issues.apache.org/jira/browse/CALCITE-3878
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.22.0
> Reporter: neoremind
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I find many places in Calcite where _new ArrayList<>()_ is used, if the list
> is expected to be immutable or not resizing, it is always a good manner to
> create with initial capacity, better for memory usage and performance.
> I search all occurrences, focus on the core module, to make it safe, I only
> update local variables with fixed size and not working in recursive method.
> If the local variable reference goes out of scope, if resizing is needed,
> things will work normally as well, so no side effect, but for the "escaping"
> case, I am very conservative and do not change them.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
