som-snytt commented on code in PR #1026:
URL: https://github.com/apache/incubator-pekko/pull/1026#discussion_r1468539619


##########
stream/src/main/scala/org/apache/pekko/stream/impl/fusing/CollectWhile.scala:
##########
@@ -43,18 +44,17 @@ private[pekko] final class CollectWhile[In, Out](pf: 
PartialFunction[In, Out]) e
       private lazy val decider = 
inheritedAttributes.mandatoryAttribute[SupervisionStrategy].decider
       import Collect.NotApplied
 
+      @nowarn("msg=Any")
       override final def onPush(): Unit =
         try {
           // 1. `applyOrElse` is faster than (`pf.isDefinedAt` and then 
`pf.apply`)
           // 2. using reference comparing here instead of pattern matching can 
generate less and quicker bytecode,
           //   eg: just a simple `IF_ACMPNE`, and you can find the same trick 
in `Collect` operator.
           //   If you interest, you can check the associated PR for this 
change and the
           //   current implementation of 
`scala.collection.IterableOnceOps.collectFirst`.
-          val result = pf.applyOrElse(grab(in), NotApplied)
-          if (result.asInstanceOf[AnyRef] eq NotApplied) {
-            completeStage()
-          } else {
-            push(out, result.asInstanceOf[Out])
+          pf.applyOrElse(grab(in), NotApplied) match {
+            case _: NotApplied.type   => completeStage()

Review Comment:
   The clunky pattern is just to avoid a clunky `eq`.
   
   You might use a local val to avoid "cost of obtaining the value".
   
   This is like pattern match on List with Nil case, where match on `::` first, 
then just `case nil`. It's nice if you have a type to check.
   
   An example where just "obtaining the value" is expensive is `NoSymbol` in 
the compiler, because of the "cake". There are edits trying to choose between 
`eq` and `==` but that is swamped by the fetch. It is outweighed by style 
concerns.
   
   If you can measure a difference reliably, then of course you are equipped to 
choose.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to