Custom EventListener Testing

Introduction

The previous post has looked into creating custom EventCounters and testing them. In this post I will look into how to unit test custom in-process event listeners. The previous post has given an overview on the key classes and their behavior for event counters in .net core. Reading that post will help with the understanding of this post.

Custom EventListener

First, I will create a custom event listener, which listens for periodic updates from cpu-usage EventCounter from System.Runtime event source. I would like to test that the custom listener logic within this listener works as expected.

Find out more


EventListeners for Hardware Resources

EventSources and EventListeners

.net core infrastructure for event counters consists of a good couple of classes. This post will details the classes and their responbility when it comes to in-process event counting. I am writing this post by reverse engineering part of System.Diagnostics and System.Diagnostics.Tracing from their GitHub repo.

EventSource, EventListener, EventCounter (DiagnosticCounter), CounterGroup, EventDispatcher. Not all of these classes are relevant when simply creating or consuming counters, but we need a good understanding when it comes to testing. The purpose of this post is to detail their responsibilities and their internals.

Generally, to create our own set of counters, we would need to derive from EventSource class. In this class typically in the constructor we can create counters such as PollingCounter, IncrementingCounter, etc. Each counter has a name and a reference to containing EventSource derived class.

Find out more


Performance Improving a Sudoku Resolver .net application

In this post, I will investigate how to improve the performance of a sample Sudoku resolver application. The base Sudoku resolver is a .net core console application written in C#. The original source has been written only in a couple of hours, while performance was not the main priority. In this post, I will gradually improve the performance of the application and document the process step-by-step. These articles will also touch on how some of the tools such as PerfView, dotnet-counters and BenchmarkDotNet can be used to measure performance. The goal of the optimization will be to reach a mean execution time below 500 us with a unimodal distribution and minimal allocation per run. By run I mean once the application is started, a run is parsing an input of a Sudoku and providing a solution for it. The application may execute multiple runs during its lifetime as a process. For repeatability of the performance tests, I have chosen a sample Sudoku input that is used throughout all the performance tests.

The goal of this post is to represent the ideas that may be used to optimize applications. I will try to avoid showing huge classes or large code, but I will show slices of the code that is modified in an iterative fashion. At this point, I would like to highlight that I am not optimizing the algorithm to resolve a Sudoku, I am optimizing the code that executes the algorithm to resolve the Sudoku. The algorithm itself will not change throughout the optimization process.

Why does performance matter in these days? In a cloud first, serverless world, where computation is bought on memory and CPU used by our application, we can only serve more request for the save money if our application is efficient - also we end up with a more "environment friendly application" by using less power with potentially less CO2 emissions.

Base Application

Find out more


Inlining Code 2

This post is the second part of a 2 posts long series, discussing inlining in relation to DCE and exception handling.

Introduction

This post is about code inlinig by the JIT compiler and Dead Code Elimination (DCE).

  • Code Inline: call of the method at the callsite is replaced with the invoked method body.

  • DCE: Modern compilers are smart enough to detect code segments, that has no effects, hence they can be removed.

Find out more


Inlining Code

This post is the first part of a 2 posts long series, discussing code inlining in relation to DCE and recursive methods.

Introduction

  • Code Inline: call of the method at the callsite is replaced with the invoked method body.

  • DCE: Modern compilers are smart enough to detect code segments, that has no effects, hence they can be removed.

I will walk to through two examples showing these compiler features in action in regards to exception handling and recursive methods. At this point, I expect the reader to have a good understanding on both of the above compiler features.

Find out more