DEV Community: Pablo Miranda

Memory Management

Pablo Miranda — Sun, 02 Apr 2023 00:15:30 +0000

When dealing with memory management on .NET garbage collection comes to mind as something that you have to constantly monitor. Understanding how your program interacts with the garbage collector makes a difference.

Memory Allocation

How windows manages the heap and new allocations maintaining lists of free slots to reduce fragmentation, with native code applications you always have the option to maintain memory allocations as linear as possible with or without a custom allocation scheme. In .NET memory segments are controlled so objects are allocated near each other.

So when allocating an object the value to allocate it is set to the buffer information which will look for the next available byte and compare it against the end of the allocation buffer looking for a space where the object would fit, then is always better to work with multiple objects at a time rather than treating objects like they work in solitary.

When garbage collection occurs objects may be moved to different locations to free space on the segments which is expensive now that all references have to the objects have to point to a different -new- location.

What can you do to help the GC?

First thing would be to reduce the memory allocated in the first place by for example:

Removing unused fields.
Keeping the size of primitives as small as possible
Allocating memory upfront
Initializing objects when and if needed

The general rule of thumb is that objects should have limited lifetime span so the garbage collector wouldn't have to considered them at all. On the other hand objects that you will use over a larger span have to be referenced once and should be kept and maintained to be reusable.

Small objects should be allocated right before using them and large objects must be allocated before hand so the cost of allocating them comes at an earlier point and not in the middle of processing your program.

Temporary objects must be set to null when no longer needed and the same applies for members from a static class when its values are no longer needed. Having nested object references become a problem as well because the objects lifetimes are hard to predict.

Disposable Objects

Destructors are triggered by the garbage collector one after the other after a collection, as long as Dispose is called before a recollection the object will be eliminated without needing to call the destructor. So the Dispose pattern should be used instead of having a destructor with all the clean up logic in the Dispose method, this code should be as simple as it gets only touching memory that belongs to the object without any guarantee that it may be still valid.

Marshalling

The problem with copying buffers is that data gets moved, for example when using LINQ to modify a list from an array of elements this data is copied to .NET memory space and then returned to your program memory space which has a huge cost.

Generally objects should be created and destroyed quickly other wise if you need them during the timespan of your program their reference should be kept forever. With static references objects live through the lifetime of the program and should be handled within pools.

Large collections of elements should be pooled as well referencing them as needed, one way to do this is to manage the pool with the disposable pattern where the Dispose method puts the pooled object back into the pool to be reused keeping in mind that you have to have full control over it.

When pre-allocating large objects what should follow is a forced collection of the GC calling GC.Collectso the large object can replace what was going to get rid as garbage and at the same time compacting the heap because of fragmentation. Once this objects are on the segment where they will live for the lifetime of the program they can be safely pooled and referenced from there as needed.

Caching

When you want to keep around objects that are expensive to create Weak References become useful for caching them, this is something to consider when memory available is restricted like on mobile devices or when large objects are easy to create and there is no need to have them around if you are not using them

Managed code

Pablo Miranda — Mon, 09 Jan 2023 23:57:51 +0000

Manage coded as I wrote before comes with a cost because the safety net that brings have multiple layers of complexity.

Benefits

Managed code over unmanaged code indeed has a plus side.

Type Safety

Enforced by the compiler and runtime, so objects are used as they are plus boundaries, overflow detection, here what's really important is that the heap can not be corrupted due invalid pointers or memory access violations.

Memory is managed, with some advanced language features found on a higher level of abstraction. Reflection certainly provides a dynamic component managing extensions.

Drawbacks

There is no access to the full processor instruction set.
New windows features come first to C/C++ windows sdk and some functionality still don't have any managed wrapper.
There is no direct memory access plus no control over the memory layout of structures.

Performance

This high-level managed code is translated to Intermediate Language, then when the code is run the CLR invokes the JIT compiler to convert your IL to assembly code where most important code optimizations happen and also performance suffers this one time hit and from then you always get the compiled version.

The quality of the generated code is not on our hands which gets better on each .NET framework release. Memory management does have some points in favor with a properly configured garbage collector, since it compacts the heap memory fragmentation is less of an issue.

Another issue is that memory allocations are trivial and generic API features come with expensive implementations in favor of make them universal and here is the why and where we want to understand better the software we write as developers.

Performance Awareness

Pablo Miranda — Mon, 09 Jan 2023 01:13:44 +0000

When considering performance, what you have to care about is having a metric -usually- elapsed time from which you can notice change and identify time consuming data operations. This is something you want to do early in development even on prototypes as it will usually challenge your design overtime.

This will go from design to maintenance on the product cycle because you can always lose performance, so the key here is to measure again and again, without loosing focus on correctly interpreting the results which is as important as measuring in the first place.

A hard thing to grasp here is that performance has layers of complexity, programs are complex and run on even more complex hardware, on top of it you find abstractions (memory, caches, OS, runtimes, garbage collectors, etc). This can be overwhelming with so many thing to be measured plus tools that come along with it.

What to measure and what relationship among measurements is important, setting goals through metrics.

.NET Framework

The focus here will be .NET framework, so much of it just works, with .NET you have managed applications which are put on a safe operating environment between the application and the operating system, there is overhead by not having direct access to Windows APIs nor direct access to the processor.
Having this safe net on your program is good but not free, enables you rapid development which most times derives on poor code resulting on slow bloated applications.

Is always easier to just blame the framework for all problems, performant code does not come easy, that's for sure.

Big changes on your code base are always easier to introduce in the form of a design decision due to experimentation rather than trying to change your application when is already big and complex where dependencies have to be take into account.

FYI

I will try to keep things balanced on how I will approach .NET framework details and IL on the other side, so our focus will be on how to benefit from the .NET framework but also recognize and know when you have to sacrifice so call benefits of .NET as well.

What you get out of your application, making the most of it comes from deep understanding of your own code, the framework, the OS and most important the hardware itself.

Programming with .NET

Pablo Miranda — Sun, 08 Jan 2023 21:35:55 +0000

I usually think of coding as what programming has become over the years, copy-pasting code without much thought or deep understanding of what it does. This is almost generally true among web coders.

Programming indeed is complex, although the easiest thing to do is writing bad code, we will focus on things that are on us developers reach and not on what is under control of the .NET runtime.

We will focus on what makes good code better, anyone can start by asking non trivial questions about application architecture, algorithms, data structure selection, and so on.

The key to write better applications is that first you have to realize that there is no bug-free code, and always there will be time to run and fix problems on your applications.

Applications

Once you are confident that the application runs properly after debugging and testing, then you can start thinking about performance goals for your application. We will agree here that are enough smart developers working on the .NET runtime so we will focus on what is on our side as developers.

The biggest problem with performance is that usually comes late, and is the hardest problem to fix once it was baked into the design as a misrepresentation of data.

Data

All applications can be defined as algorithms that transform data and data transformations that happen on your applications can be a key aspect of the overall performance of it. The basic representation of data that will be manipulated places strong constraints on performance if it is poorly chosen -XML JSON DB- specially if is detected late into the product cycle, trying to change it then will be expensive.

Welcome

Pablo Miranda — Sun, 08 Jan 2023 21:09:04 +0000

Hello everyone, what better way to start the year by putting some time on sharing what experience provides us over the years of playing around with .NET framework plus C#.

Everyone is welcome to come along but content here won't be a language reference nor aimed to beginners but I will try to keep things simple so everyone can get something useful out of it. Having some depth experience with .NET already will come handy.

About me

I always thought that it all started back when I used to play around with the computer (just before windows 3.1) then a bit serious with IBM’s manual and DOS, is quite interesting how focus can change in an instant.

I remember that I wanted to install a game -Hocus Pocus- but run into an error (zipped file) and it was the first time in which I had to do such thing since it was always direct install from floppy. So I got introduced to ‘pkunzip’ -if I remember correctly- and after that I started wondering:

What else can I do?

So I jumped back into that IBM manual and worked with DOS 6, that way I mainly stayed at the console and only moved to GUI on Windows XP. Now for “programming” started with batches on DOS then Turbo-C and finally Visual Studio 6 with VB for about a year.

I have had such a peculiar experience with .NET and C#. At first I didn’t like the GUI so I stayed at the console until Windows XP was available and used it until 2010-2012, besides XP I have only used Windows 2000 Professional for administration, back then I started using CentOS -my fav distro-. This went back to back with windows administration as I used to replicated things I learnt on both, since then when I had to do something on C I would choose to do it on Linux.

Now tools for development, my all time favorite combination was Visual Studio 2012 with Windows XP and C#, this combination I used constantly up to 2020, it was the only VM I had on my MacBook 2012 to work with Windows Forms and anything related to Microsoft’s products. Since 2012 my main OS has been either macOS or fedora and used Windows when needed.

I started using .NET Core on Red Hat at first and eventually moved completely to macOS when it was supported so the key is to adjust to whatever it comes.

Update Jan 2022 Since Jan 2021 I focus almost exclusively on Apple’s ecosystem on M1 so no Windows VM for the moment, only Swift for iOS, iPadOS and macOS.

Update Jan 2023 Regarding .NET, I use it with C# as always but now in a mix with maths, physics and 3D stuff from time to time.