Live data from Hacker News

Allocation is cheap in .NET until it is not

tooslowexception.com

1–10 of 67 posts

Re: Allocation is cheap in .NET until it is not

#2
This article demonstrates why generational GC with a bump-allocating nursery is so important. Without a semispace copying collector (which is usually impractical without a generational GC) you can't have bump allocation at all. Not having that fast path is a huge performance loss, as this article demonstrates.

Re: Allocation is cheap in .NET until it is not

#4
post #3

This brought memories of that pattern (flyweight?) where the data was stored outside the objects, possibly in an array. An object was instantiated only to hold an index to the array position and allow access. That's dirty cheap!

It's still commonly used. The NFX library has Pile which does this well for holding large data:

http://nfxlib.com/book/caching/pile.html

https://www.infoq.com/articles/Big-Memory-Part-1

Re: Allocation is cheap in .NET until it is not

#5
post #3

This brought memories of that pattern (flyweight?) where the data was stored outside the objects, possibly in an array. An object was instantiated only to hold an index to the array position and allow access. That's dirty cheap!

That pattern can be done in .NET via native memory allocation (MarshalInterop and SafeHandles).

With the latest C# 7.x features will become easier to use it.

Re: Allocation is cheap in .NET until it is not

#6
post #3

This brought memories of that pattern (flyweight?) where the data was stored outside the objects, possibly in an array. An object was instantiated only to hold an index to the array position and allow access. That's dirty cheap!

It's still commonly used. The NFX library has Pile which does this well for holding large data: http://nfxlib.com/book/caching/pile.html https://www.infoq.com/articles/Big-Memory-Part-1

This pattern was also used by Java and .NET for implementing cheap String.substring calls where all substrings would use the same underlying array with just offsets changed. Unfortunately it turns out that people read entire files into a one big String and then have a reference to just a small piece of it (via substring) marking the big underlying array as reachable for the GC holding a lot of memory for no reason. That's why new implementations of substring always copy:)

Re: Allocation is cheap in .NET until it is not

#7
post #3

This brought memories of that pattern (flyweight?) where the data was stored outside the objects, possibly in an array. An object was instantiated only to hold an index to the array position and allow access. That's dirty cheap!

It's a common pattern — e.g. a lot of C++ libraries have some sort of string piece type.

Re: Allocation is cheap in .NET until it is not

#8
post #3

This brought memories of that pattern (flyweight?) where the data was stored outside the objects, possibly in an array. An object was instantiated only to hold an index to the array position and allow access. That's dirty cheap!

good old fashion separating data from logic.

Re: Allocation is cheap in .NET until it is not

#10
post #6

Earlier quoted context omitted.

It's still commonly used. The NFX library has Pile which does this well for holding large data: http://nfxlib.com/book/caching/pile.html https://www.infoq.com/articles/Big-Memory-Part-1

This pattern was also used by Java and .NET for implementing cheap String.substring calls where all substrings would use the same underlying array with just offsets changed. Unfortunately it turns out that people read entire files into a one big String and then have a reference to just a small piece of it (via substring) marking the big underlying array as reachable for the GC holding a lot of memory for no reason. T…

I know this was changed recently-ish in Java, but I hadn't heard of anybody doing the old substring trick in .NET, do you know when they cut over?
Post reply on HN