NullReferenceExcepti0n, a plumber that connects the dots...

In my days I am sometimes wondering why we humanins are so hateful to computers. We ask them to make a job that is not used, even we order them to do it twice or more in a process flow. A time ago I was shocked when I saw a code review that was approved by a senior developer with more than 8 years of experience and written by other senior with more than 10 years of experience in the .Net area. What killed me is that nicely looking code makes more noise and brings no value, but cost precious CPU ticks. Please read below listing: What do you think? I hope that this not look familiar to you!!! So let's try to add some context, so the parameter is received by api endpoint, and then passed down. Now firstly we can see that it is converted from string to int , in a safe manner using int.TryParse . Next we see the same method invocation (as Int32 is return type of try/parse) and then this parameter is passed down to document generator, then to submethod where we can see an expensi

In recent post  You are evicted!  I was planning to use akka.net streams solution to solve memory pressure problem. Today I have a solution that I will be testing.  Mainly I used an example from akka.net  manual  pages. As I was stuck on the flow (it is a bidirectional flow, where every byte received can have a response to the sender) I asked on the akka.net discord server  for help as I was stuck in one of the stages, and my code was not compiling.  The TCP flow is very specific as it needs to start with ByteStream and finish with same, as what ever is on the end of the flow is sent directly to the other connected side. The flow has stages listed below: Framing - that splits incoming stuff in chunks by delimiter (new line in our case, but can be a series of bytes as well) Then we are converting it to string Grouping (this is a key for the solution as sending one line over http is a killer) Final stage is the place where it will be send over http, but for illustrative purposes in gist

 In one of projects we had a challenging situation, our data process flow was interrupted by evicted pods in Kubernetes. That was occurring when our system was in a busy hour mode so incoming stream of data was up to 30MB/s. In the pod we had a C# program that was transposing incoming data for a database entity and pushing that over http request. Our scheduler was prepared to scale up and out, so we could use more hosts and pods when in the busy time, but that was not working as expected... When new pod was created all the data connections were directed to it and ..... bum eviction (to much  memory consumed) - as it was buffering all the data and not able to push it out to http. Our precios data in transit was lost, next pod had a similar scenario - so in short words we were screw up. We had some ideas to fix it. let's check memory usage after each packet received (huge performance drop - we had to have 4x more pods for a standard traffic and up to 6 in peek time) let's limit n

 In recent years I remember a discussion about a 3 lines of code, it was something easy, so let's have a look at this: As we can see, an one liner statement was replaced with a string builder.  As this is a reset password, then we shall not focus on performance as our users rest password once in a year, but the discussion was based on a style how that was done, so let me bring what we discussed. Frist, a string builder is a great tool for dynamic text and in this case we have only one variable - so it is overkill. Secondly templating shall be moved away from logic as this is pure implementation of the process. So I ran a benchmark, just to confirm that SB is an overkill: Now I will add a static string that will be our template, and we can see if string.Replace can help us (imho string.Replace is a heavy and will use more memory, thus it can be heavy on CPU too). As we can see, the refactor gave us a nice looking code, one line for the template, but we lost a bit on the performance

Once upon a time in 2023 in the wild west space a code review happend. As it is normal with inherited legacy systems and code, we not always have ability to refactor incoming data shape or values - BUT - we have all the rights to shape objects that are used in our application to be nice and clean. Snipped bellow is an example of not dealing with that approach, rather a lazy way just to  close a ticket. As there is a hidden gem, that list in not needed, as stored procedure returns only one record with data, so we have ability to simplify thing down in the processing stream.  And we can start form a proper name for internal variable to match C# codding standards, moreover as this is a mapping only we can reduce the text to minimum. Now let's get rid of the "if" statement as this is pain to my eyes, as we are dealing with nullable, let's check for a value and then assign "0" or a value. So now, as we know that we have only one record here, lets introd

In last blog click  we have the chance to refactor a logic expression to be more developer friendly, but it was generating more IL code lines. I was wondering if that will have an impact on the performance (u know when u use a language that is focused on extending your product not on high performance - then this is a bit of over engineering case 💩💩💩). So yes, I made a benchmark in LinqPad making my friend Selciuk unhappy a bit, but the results are very interesting. In 2 form 5 test cases, refactored code was performing a bit better, but I am more happy that in the other three cases it was not terribly slow, with a maximum of 4% slower. So having those results, let's say that it is more important to write code that is easier to extend!  If you willing to write a high performance stuff - then you need to be ready to decipher every line, every time when you read it :D.

 How many hours I spent on decoding stuff that does not need to be decoded... We are reading and repeating decode every time we see piece of logic. On snippet above we can see just an if statement and 4 different logic cases to be resolved. Our brain will try to imagine all the string details before will enter inside the execution block. Can we help our brain to work faster? Sure we can do it! let's name first logic case as var  johnBlogEntryCode  =  a.Length>15 && a.Contains("11")   the second one as var  maryBlogEntryCode  = a.Length<20 && a.Contains("2") and finally var doWeHaveOurBlogEntries = johnBlogEntryCode | maryBlogEntryCode How that looks now for you? I can bet an old fart that you just read stuff on the left and not go into details on the right - true? This is one of the simple but CHALLENGING methods when we need to understand what are we doing in a particular piece of code an NAME IT!     As we can see on the screenshot t

 What we shall expose to client (and it is really a case)? My last blog entry (click) was about messaging and the way we can start refactoring our app by splitting activities internally, now let's have a look from other side when a decision need to be made to expose messaging wisely.  Let's have a look at real life story that occured in one of the places where I was working. A team was working on a monolith to split it up to smaller services (ach we want to say micro services). So they integrated messaging using one of the cloud providers (out of the box solution).  As the team was successful in their job - a member from other product suggested to use the message bus to speed up integration process and all agreed and were happy. The time goes on and a client got access to the bus just to speed up some things... So what do you think happened there? As the team was progressing with their job they realized that they can't: - guys had to constantly maintain access to the bus a

Messages. messages all about messages. Is that a real thing - do we need them? Messages are nasty, you send it in one piece of code, receive in other and you can't just debug that. No function calls, no stack trace - so how you people like those messages? Primero messages are great way to allow separate application components, especially when we are inheriting legacy solution with huge number of dependences. To start with messaging, we don't need Kafka, MSMQ, rabbitMQ or other animals - we can start with stuff that are already in our .Net tool case.  In below example we use a very basic approach that enables us to avoid method calls in destination with our parameters and we are using queue so we are messaging each other! let's define a queue(s): Then we can add a producer (something that will be adding messages, like our web api controller): and a consumer (like our database writer): And as you can see, our data is enriched by database query and send to next processing step

 This could be a trivial issue or catastrophic performance issue at the end of the day. Linq is so easy to use and abuse, so most of developers are not aware that some of the compute is moved from their server to database instance.  Is this a bad thing? As always it depends on many factors, as application load schema, how it is architected, what kind of load balancing is used, etc, etc.  In many scenarios with business applications build in C#, we have a server and a database, where server can be behind a load balancer (so we could have 3 instances) and SQL server is in a cluster with log shipping (mostly in a hot/cold configuration) for redundancy.   A here is the catch: we always can add more workers behind the load balancer (just more pods in Kubernetes), but it is hard to scale-up database service. Unless we use CQRS and/or caching then we are in the performance trap, as shifting compute to DB means less resources available for other queries. So how we can do it? Have a look at sni

 As we shall learn all life and never retire from learning - today my closed brain read rfm about using benchmarkDotNet in LPad, so  one can benchmark a code snippet by just selecting it and pressing CTRL+SHIT+B  The tests were done for .Net 5.0, 6.0 and 7.0 framework versions. As you will see, the results are pretty interesting (and I repeated them a few times)  giving us a few conclusions: I was told to use string.Empty instead of "" for performance, not a case in those results, especially for v7.0 I am not sure if the benchmark runner has good ability to test those small operations and I even repeated in one case creation of  a string variables, but the results vere proportional. I need to use full BenchmarkDotNet next time to compare those results, but inside I am curious why the is so big change in the timing. I will still use string.Empty as for me it is easier to decode the code when reading

This is one of those code reviews where I am not sure if I shall cry or call for more ice-creams to cool down. Someone was tasked with a function that is adding a checkbox to the dataTable and then making an API call with selected Ids to the backend. A trivial task we can think, but not as always. Let see a bit of simplified frontend code, where rows selected are taken form checkboxes plugin for dataTables and that comes as object so it need to be iterated to get values and store them in new place. In this particular case an engineer decided to push it to comm separated values, the assign to model and push to an api endpoint. Is this bad - hmm it depends - if we will use this string as a query parameter - that is fantastic (no JSON conversion needed on client and server side), but pushing it to string as an model is a no, no. Why? 1. performance overhead on client and server 2. native form change (array of integers to string)   - that need to be redone on an api side 3. now see the obj

 In Linqpad 7 user can execute BenchmarkDotNet, as I love LinqPad for it is simplicity and ability to test somestuff without the burden of creating a project. After installation (of LinqPad) we can find a predefined query called BenchmarkDotNet, with an example benchmarks defined, so we can start 'doing stuff' After first run we can see that all methods with attribute [Benchmark] are executed in the harness, so we can start digging.  Right click on the query and select use as a template - so we will not use the orginal one.  The simple code is here:  gist  (and at the end of this post) Creating a class for each method allows to have it nicely displayed on the results pane. From the benchmark results we can see  that there is nothing to worry with the practicular code as both methods have fairly same time of execution - and let's try to add more steps (up to 10 and see if we will be still close or switch will take an advantage) And the results are very interesting (who is us