[
https://issues.apache.org/jira/browse/METRON-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895209#comment-16895209
]
Otto Fowler commented on METRON-2195:
-------------------------------------
[~tigerquoll], as with [~simonellistonball]'s comments I'm confused here.
Lazy evaluation of function parameters does not, as far as I know stop the
evaluation of methods that are written as the parameters themselves, since it
is the result of that method that is actually seen by the called method, not
the method itself.
It seems that we are confusing things here. I would like some reference to
some documentation that says that there is a way in java ( or any language
really ) where
{code:java}
object.functionCall( otherObject.otherFunctionCall());
{code}
Does not result in otherFunctionCall() being executed, because as far as I know
it will always be evaluated by the compiler as
{code:java}
object.functionCall( result object of otherObject.otherFunctionCall )
{code}
In which case the lazy evaluation INSIDE the function does not matter.
> Add defensive log level checks when constructing logs is expensive
> ------------------------------------------------------------------
>
> Key: METRON-2195
> URL: https://issues.apache.org/jira/browse/METRON-2195
> Project: Metron
> Issue Type: Improvement
> Reporter: Otto Fowler
> Priority: Critical
>
> There are instances where we log, and output strings for json objects and
> other things that are quite expensive.
> These are done regardless of the log level being enabled and can increase
> performance significantly:
> https://gist.github.com/mmiklavc/7fd6af13bfa0ca05d9b3f4e7806c8d77
> https://github.com/apache/metron/blob/master/metron-platform/metron-writer/metron-writer-storm/src/main/java/org/apache/metron/writer/hdfs/HdfsWriter.java#L127
> We need to find places where this happens, and employ the best practice check
> for the log level being enabled ( best practice if your parameters or log
> message construction takes a lot of time ).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
