如何将计时器指标添加到java.util.Stream

Question

The general concern is how to add timing metrics to various parts of a java.util.Stream execution. At the termination it is easy to time the total operation, eg, (using the codahale library)

try (Context ctx = timer.time()){
   stream.count();
}

But what about "per-item" timing? Or how to add timers to the intermediate portions of a stream, eg, timing how long the first 5 stages of a 10 stage stream takes?

It is easy to time individual steps in intermediate stages merely by adding timers to those methods. And the initial Spliterator code could measure the time between the first occurrence of tryAdvance and the close() method (it would have to add an onClose Runnable to the stream it generates). That at least allows stream-supplying libraries to use Timers even though they don't know how their streams are being transformed and consumed.

It would be wonderful to write something like:

List result = stream
   // stream ops ...etc...etc
   .timeTotalOperation(totalOpTimer) //time between first traverse and close()
   .timePerItemOperation(perItemTimer) //"forEach" timer at this stage
   .collect(Collectors.toList());

but we can't add these methods to the Stream interface, obviously.

It doesn't seem to make any sense to wrap the Stream with a delegating pattern. As far as I can tell, the "right" implementation is to tap into the Pipeline classes and they are inaccessible and (possibly) subject to change.

I can't even extend the Collectors to time the terminal stage since the classes are final or package visibility. While I can roll my own Collector and call the stream(Collector) myself, there goes all the useful functionality in Collectors. However, it should be possible to write a CollectorDelegate class that wraps an item returned from the Collections, eg,

List result = stream
   .collect(new TimingCollector(Collectors.toList(), totalOpTimer, perItemTimer));

It must be admitted that the concept of "per-item" is "iffy", given the complexities of Stream use cases. There are probably operations where "per-item" timing doesn't even make sense. But even for the simplest use cases for Streams, I can't figure out a clean way to do this.

Such an open-ended issue poses too many questions for a good thread, so let me attempt to pose just one. Read a stream from a database, convert to java objects, measure just the reading from the database and the conversion to java, then forward the stream to a consumer to more work, but do not time that portion:

import java.util.function.Consumer;
import java.util.stream.Stream;


interface SQLResultSetSupplier {

    default Stream<Object[]> generateStream() {
        return Stream.generate(this::getExpensiveResultSet);
    }
    Object[] getExpensiveResultSet();

    Object expensivelyConvertToJava(Object[] row);
}


public class StreamTimerExample {

    public void example(SQLResultSetSupplier supplier, Consumer<Object> reportConsumer) {
        /**
         * Supplier performs a database query and returns a Stream on the ResultSet.
         * Convert each row of the ResultSet to a Java object.
         * Measure JUST THE ABOVE on a per-item basis.
         *
         * Then send the stream on to a Consumer, e.g., to generate a report.
         * Do NOT measure this second portion.
         */
        Stream<Object[]> baseStream = supplier.generateStream();
        Stream<Object> expensiveOperationStream = baseStream.map(t -> supplier.expensivelyConvertToJava(t)); // measure this
        expensiveOperationStream.forEach(reportConsumer); //don't measure this
    }

}

Answer 1

My gut feeling here: you are investing your time in the wrong place.

You intend to spend a lot of time and energy to implement your own code instrumentation in the end.

Meaning: why the focus on "streams"? In the end, what matters is the overall performance of your "end user" functionality. Sure, the streams might make up a significant part of that. But you are still investing a lot of energy to create visibility ... for a very specific "corner" of your system.

I would suggest a different strategy: rather use a profiler and measure end-to-end use cases. And then, you could still (pretty easily) configure the profiler to restrict measurements to stream operations.