Github user arunmahadevan commented on the issue:
https://github.com/apache/storm/pull/2532
+1
---
Github user ptgoetz commented on the issue:
https://github.com/apache/storm/pull/2532
+1 Nice catch. Agree on performance -- tick tuples are sent infrequently
enough that the optimization isn't necessary.
---
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2532
@satishd added comments. Commit amended because it is tiny change.
---
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2532
@danny0405
If it's in critical path, it could bring perf. hit, not only from creating
object but also from GC. We are targeting to emit millions of tuples in a
second.
In this case,
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2532
@satishd @danny0405
Sorry guys. I missed while commenting, corrected now. **I don't think it
brings any perf hit.** I wrote it opposite way. ;)
---
Github user danny0405 commented on the issue:
https://github.com/apache/storm/pull/2532
@HeartSaVioR
Create an object is very lightweight, is should not have any performance
hit.
---
Github user satishd commented on the issue:
https://github.com/apache/storm/pull/2532
@HeartSaVioR It may be helpful to have a comment on why it was changed with
JIRA number so that same change is avoided later.
---
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2532
@satishd I don't know about the perf hit, and I don't think it doesn't
bring actual perf hit, but anyone would think it is just weird to create same
tuple every time, so easy to break it again.
Github user satishd commented on the issue:
https://github.com/apache/storm/pull/2532
@HeartSaVioR Was there a reasonable perf hit because of creating tick tuple
instance whenever it is executed in timer?
---
