[jira] [Resolved] (STORM-3205) Optimization in TuplImpl

["Robert Joseph Evans (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/STORM-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Joseph Evans resolved STORM-3205.
----------------------------------------
    Resolution: Fixed

Thanks [~roshan_naik],

 

I merged this to master.

> Optimization in TuplImpl
> ------------------------
>
>                 Key: STORM-3205
>                 URL: https://issues.apache.org/jira/browse/STORM-3205
>             Project: Apache Storm
>          Issue Type: Improvement
>          Components: storm-client
>    Affects Versions: 2.0.0
>            Reporter: Roshan Naik
>            Assignee: Roshan Naik
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 2.0.0
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Wrapping {{TuplImpl.values}} with Collections.unmodifiableList() turns out be very expensive. Its intention is obviously to check and prevent accidental tweaking TuplImpl once created. Given the high cost, if needed, we can limit this extra checking mechanism in debug/dev mode. Being in the critical path it means several thousand/million additional allocations per second of the List wrapper object .... proportional to the number of bolt/spout instances.
> *TVL :*
> | |throughput (k/sec)|cores|mem (mb)|
> |*master (#f5a410ba3)*|412 |4.26|103|
> |*storm-3205*|547  (+33%)|4.09|132|
> {{+cmd:+ bin/storm jar topos/storm-loadgen-2.0.0-SNAPSHOT.jar org.apache.storm.loadgen.ThroughputVsLatency *--rate 550000* --spouts 1 --splitters 3 --counters 2 -c topology.acker.executors=0}}
> *+ConstSpoutIdentityBoltNullBolt :+*
> | |throughput|
> |*master*|4.25 mill/sec|
> |*storm-3205*|5.4 mill/sec (+27%)|
> +cmd+: {{bin/storm jar topos/storm-perf-2.0.0-SNAPSHOT.jar org.apache.storm.perf.ConstSpoutIdBoltNullBoltTopo -c topology.acker.executors=0 -c topology.producer.batch.size=1000 400}}
> *Note:* The perf gains are more evident when operating at high thoughputs w/o backpressure occurring (i.e. some bolts have not yet become a bottleneck)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)