> On April 3, 2014, 5:12 a.m., Guozhang Wang wrote:
> > Just curious: which part of the code is the main contribution to the 
> > handling overhead?
> 
> Joel Koshy wrote:
>     Tim can correct me if I'm wrong but I think the overhead was largely in 
> the sort.
>     
>     Thanks again for the patch. I'll get this checked in.
> 
> Timothy Chen wrote:
>     From profiling with 1000 topics actually the largest contribution looks 
> like was the metadataCache.map(_.topic) call, which originally we call for 
> each topic that is being requested. I moved it so that we just do it once.

Sorry left out an important detail, the most time was spent in HashSet.updated0 
call which looks like it's from metadataCache.map(_.topic).toSet. The 
construction of the new set seems to be expensive and we do it for each entry 
of topic and partition.


- Timothy


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19957/#review39402
-----------------------------------------------------------


On April 3, 2014, 1:39 a.m., Timothy Chen wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19957/
> -----------------------------------------------------------
> 
> (Updated April 3, 2014, 1:39 a.m.)
> 
> 
> Review request for kafka.
> 
> 
> Bugs: KAFKA-1356
>     https://issues.apache.org/jira/browse/KAFKA-1356
> 
> 
> Repository: kafka
> 
> 
> Description
> -------
> 
> KAFKA-1356 Improve topic metadata handling in kafka api
> 
> 
> Diffs
> -----
> 
>   core/src/main/scala/kafka/api/TopicMetadata.scala 
> 0513a59ed94e556894b3515dc38666ee9a66ae3d 
>   core/src/main/scala/kafka/controller/KafkaController.scala 
> fcabd0da201ccd478f5884bcca9b75a8c8ea8373 
>   core/src/main/scala/kafka/server/KafkaApis.scala 
> c068ef69207c351eec413a595f1747c59f8b3983 
> 
> Diff: https://reviews.apache.org/r/19957/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>

Reply via email to