Allocations

Memory allocations on the server, particularly in higher level languages, can cause substantial performance degradation. Avoiding them can cause code complexity which largely defeats the point of using a higher level language. SocialStack's API aims for the best of both worlds: A non-allocating core which is also very straight forward to use.

When SocialStack allocates

Most allocation happens on first time calls of something or during startup. Aside from that SocialStack agressively pools and ensures that all major code routes do not allocate unless absolutely necessary (such as any sort of create endpoint - that will inherently allocate).

When it does not

SocialStack has a filter mechanism which has the primary role of returning lists. Internally, this whole filtering and listing mechanism is non-allocating. So long as your filter strings are constant, the filter object is compiled once and then comes from a pool whenever you call Where.

var name = "Hello world";

Where("Name=?").Bind(name)

Because the filter string is constant, the query described by the filter is compiled into dotnet IL once and the resulting filter objects come from a pool. This means textual query like calls have near native performance without allocating anything.

Related to the list system is also includes. Includes avoid allocations by being effectively a continuous stream which the frontend javascript then lightly rearranges into a nested structure.

Websocket messages are also practically memory free as the whole protocol is non-allocating. It generally tries to make it clear when a method you use will allocate something; simply passing JSON around over the websocket will result in a lot of string and JSON related allocations on the server for example.