Provide support for fixed capacity, variable length value type (inline) strings.

[The-Futurist]

Strings in C# are perceived as buffers with an (to all intents and purposes) unlimited capacity and for this reason cannot be stored inline as primitive types are. I'm proposing that consideration be given to introducing an additional string type which has a capacity declared at runtime, and thus a maximum possible length.

This then makes it possible to define classes or structs which contain strings yet have these string appear inline, within the datum's memory much as primitive types are.

This is a problem that came up in a sophisticated very high performance client server design in which we got huge benefits by being able to define fixed length messages that contained strings. In our case we simulated fixed capacity strings as properties that encapsulated fixed buffers (char or byte). This worked well but was messy because the language offers no way for us to 'pass' (at compile time) a length into a fixed buffer declaration, one must actually declare the fixed buffer explicitly with a constant.

As a result we created a huge family of types named like this: ANativeString_64 and UNativeString_128 (ansi and unicode variants) and so on, as I say this worked but was messy.

Each type was a pure struct (as in the new generic constraint 'unmanaged') so when used as member fields in other structs left that containing struct pure, giving us contiguous chunks of memory that contained strings.

As I say this worked very well but was messy under the hood and challenging to maintain.

So could we consider a new primitive type:

string(64) user_name;

for example?

Such strings could be declared locally resulting in a simple stack allocated chunk, or as members within classes/structs in which case they appear inline just like fixed buffers do...

(just to be clear I'm not seeking the capacity to be defined at runtime but at compile time, and I know my syntax won't work but wanted to convey the idea).

[HaloFour]

How do you propose something like this be implemented? Types in the CLR must have a known size, so the only method would be to emit a different (and incompatible) struct for every size of this "string".

[The-Futurist]

@HaloFour - In a similar way that fixed buffers are. In fact these could be implemented as fixed buffers but wrapped in some syntactic sugar.

[The-Futurist]

string(64)

Becomes

`struct string_64
{

int curr_length;
fixed char text[64];

}
`

plus a bunch of properties etc.

[HaloFour]

You mention that fixed buffers didn't work for your solution. Any similar solution for strings would have the same limitations, the length would have to be a constant known at compile time. Why weren't fixed buffers sufficient for your purposes?

[HaloFour]

plus a bunch of properties etc.

That's the other problem, you have to generate a bunch of separate members just to make these things workable, and they'd all be incompatible with one another, as well as all normal string APIs.

[The-Futurist]

@HaloFour

We wanted consumers of our client'server API to be able to freely declare messages, here's what a user defined message might look like (the code is unavailable to me just now so excuse typos).

public class LoginMessage : Message
{
public UNativeString_64 Name; // 'U' for unicode
public UNativeString_16 Password;
public UNativeString_32 Application;
...
}

This is how we wanted consumers to use it (and they do) but as you can see we needed a family of types (structs) for a large set of predefined capacities. We use a T4 template to generate these types. Because structs cannot inherit we could not use an abstract base class so we had to rely on an interface (INativeString).

That interface defined to/from string conversions and compare etc.

With the above design it worked well but a user could not use a UNativeString_132 if that wasn't one of the variants we created and we could not create one for every possible capacity, we stopped at like 2048 or so and went up like 4, 8, 16, 32, 64, 96, 128 etc etc.

So as you can see the consumer has no idea how UNativeString is implemented and they cannot even see the underlying fixed buffer. (There's also an ANativeString for single byte charsets).

In user code these members were interchangeable with string because of the conversion operators and so they had no idea that these were not actually strings.

At runtime a LoginMessage was a single contiguous block of memory something we can serialize very very quickly indeed. (A million instances per second on an i7 3960 CPU core).

[The-Futurist]

plus a bunch of properties etc.

That's the other problem, you have to generate a bunch of separate members just to make these things workable, and they'd all be incompatible with one another, as well as all normal string APIs.

Exactly, that's the motivation for this post, to introduce a new kind of string type that provides all this out of the box.

[HaloFour]

Seems like a very highly specialized solution that would have very narrow benefits but is massively complicated.

Exactly, that's the motivation for this post, to introduce a new kind of string type that provides all this out of the box.

You're not asking for one string type, you're asking for 2 billion potential string types, every single one of them with a separate set of members. That would certainly result in metadata explosion.

[The-Futurist]

Seems like a very highly specialized solution that would have very narrow benefits but is massively complicated.

Exactly, that's the motivation for this post, to introduce a new kind of string type that provides all this out of the box.

You're not asking for one string type, you're asking for 2 billion potential string types, every single one of them with a separate set of members. That would certainly result in metadata explosion.

@HaloFour

Well I'm certainly asking for something but not quite that. What we want (ultimately) is some syntactic mechanism that can convert this:

string(75) user_name;

into this:

struct string_75
{
fixed char user_name[75];

...various properties...
}

Or ideally a new type that is implemented better than this, but one that enables the user to declare the capacity at compile time without them needing any knowledge of the implementation.

C# could perhaps support the passing of constants into the declaration of type instances, this would probably be enough.

I mean support this:

public class MyClass (int size) // This language feature would require the supplied value be a compile time constant.
{

private fixed byte Name[size];

}

This way we could create types that must contain compile time constants, that let the consumer of the type provide that compile time constant.

Then a consumer could just code:

MyClass(79) SomeMessage;

This is I think the fundamental requirement here, a way to propagate compile time constants into type declarations...

[HaloFour]

This is I think the fundamental requirement here, a way to propagate compile time constants into type declarations...

That would involve CLR changes, and the end result is effectively the same, it's just that now the CLR has to generate potentially 2 billion different flavors of that class.

[The-Futurist]

This is I think the fundamental requirement here, a way to propagate compile time constants into type declarations...

That would involve CLR changes, and the end result is effectively the same, it's just that now the CLR has to generate potentially 2 billion different flavors of that class.

@HaloFour

Perhaps, so I guess what I'm asking is for a better way to solve this problem - on the surface this sounds rudimentary - provide support for fixed capacity (value type based and hence inline) strings - if we forget about what I've said above and what we currently do to implement this and just step back and view this as an abstract problem - are there options?

Many other languages support the idea of fixed capacity strings so in principle this isn't a major challenge...or is it?

We used fixed buffer wrapper structs only because we had no other way to deliver this, but being able to do this at a deeper langauge/CLR level might well be slicker and less messy, some of the problems you mention may be due purely to the way we implemented this and not necessarily inherent in the problem itself.

[CyrusNajmabadi]

Let's work backwards on this a bit. IN many cases the language has adopted these sorts of 'less easy to use' but 'much more performant' solutions when the gains were made quite explicit. Could you show some real world examples that would benefit from this (along with measurements)? Basically, a real world piece of code that you would envision using this.

To get the perf measurements, it would likely suffice to convert that real code to use fixed-size-buffers and see what the resulting difference was.

[HaloFour]

Many other languages support the idea of fixed capacity strings so in principle this isn't a major challenge...or is it?

The challenge here is the CLR which offers no real facility to accomplish this. Without the CLR it would be relatively easy. Languages that did support fixed-length strings, like Visual Basic, lost them in the transition to .NET.

[The-Futurist]

Let's work backwards on this a bit. IN many cases the language has adopted these sorts of 'less easy to use' but 'much more performant' solutions when the gains were made quite explicit. Could you show some real world examples that would benefit from this (along with measurements)? Basically, a real world piece of code that you would envision using this.

To get the perf measurements, it would likely suffice to convert that real code to use fixed-size-buffers and see what the resulting difference was.

@CyrusNajmabadi @HaloFour

The application is a .Net to .Net messaging platform. Because of this instances can be serialized (basically) as a memcpy, the performance of this is outstanding (as I mentioned one benchmark sees 1,000,000 instances per second on a i7 3960 core, these are small messages but did contain a few of these fixed length strings.

Other forms of serialization do not achieve these levels.

Recent advances to C# (improved ref support and generic pointers and unmanaged constraint) solve many of the problems we had to address through our lower level code and we could rewrite some of these lower layers now and simplify them quite a lot.

However the inline fixed capacity strings remain as a contrivance in our design as I explained this is quite ugly (but works very well).

Because a type layout in the CLR is the same across different machines (guaranteed if we're using the same version of the CLR at each end) it is very easy to serialize an instance (even of a class) provided all fields are inline. The recipient then simply creates an instance of the type and "overwrites" its field block with the received block of bytes that were sent.

That's the principle anyway (of course we also need to send and cache type descriptions and so on but this is all part of the low level handshaking and protocol).

All of this sits on top of a robust async socket management layer with ring buffers and stuff, but at the outer level app developers can just creates classes that inherit from Message and everything works very well and very very fast (we do runtime checks that ensure their class truly consists only of unmanaged fields, caching this info for later reuse).

Of course sending the source for this is not easy as the system contains lots of other proprietary stuff and includes some dynamic method generation for certain things.

I'm sure you get the idea though and I'm sure you can understand how this achieves very high performance.

[HaloFour]

@Korporal

Because a type layout in the CLR is the same across different machines

That sounds like a very dangerous assumption. From my understanding, unless you're using explicit layout, the CLR will layout the native member of that struct any way it sees fit, which can differ based on platform.

Anyhow, in regards to benchmarking, you're probably going to have to demonstrate that difference and why only this particular solution is suitable. And you're likely going to have to compare that to the various other high-performant serialization libraries out there.