Custom Mutable/Immutable ValueType

[Shawn B.]

Greetings,

I have created a series of objects for dealing with values at the binary
level (http//:www.visualassembler.com/binary). Each time I do anything with
them it seems I have to return a new instance of the object (look in the
operator overloads). This means it is immutable. Is there a way I can make
it a bit more, mutable? For performance reasons, of course. I've about
squeezed every ounce of performance I could and now need to focus on this
aspect.


Thanks,
Shawn

 

[Michael Bray]

I have created a series of objects for dealing with values at the
binary level (http//:www.visualassembler.com/binary). Each time I do
anything with them it seems I have to return a new instance of the
object (look in the operator overloads). This means it is immutable.
Is there a way I can make it a bit more, mutable? For performance
reasons, of course. I've about squeezed every ounce of performance I
could and now need to focus on this aspect.

Maybe its a bit obvious, but why do you have to return a value at all??
For example, you have:

public ushort RotateLeft(int count)
{
if (count >= SIZE || count <= 0) {
throw new ArgumentOutOfRangeException(<snip>);
}

return (ushort)(((Value << count) | (Value >> (SIZE-count))) &
0xFFFF);
}

why not just...

public void RotateLeft(int count)
{
if (count >= SIZE || count <= 0) {
throw new ArgumentOutOfRangeException(<snip>);
}

Value = (ushort)(((Value << count) | (Value >> (SIZE-count))) &
0xFFFF);
}

-mbray

 

[Shawn B.]

That's not the one I'm talking about. It's not an overloaded operator,
where I'm forced to return a new instance of the object. Besides, I don't
want to have to say (I already tried it this way) bin.RotateLeft(2) I want
to say (to keep it consistant with the rest of the behavior: int x =
bin.RotateLeft(2); or something.

Besides, in benchmarking 1 million iteration of each particular operation, I
find that the RotateLeft and RotateRight are twice as fast as when I use any
of the operators (35 ms for 1 million RotateLeft/Right, 70MS for 1 million
bin++, bin--, bin >>= 1, etc.).


Thanks,
Shawn

 

[Robert Jeppesen]

Hi Shawn,

I have no suggestion here. You have two choices, either keep it as is, or ditch the operators.
If you lose the operators, you'll have to have loads of method calls that changes the instance instead.
You'll lose consistency with the framework. If you suspect that oher people will be using these classes
then you'll want to keep the operators for clarity, so people will know how to use the classes.
On the other hand, you could use both. In other words, keep the operators in there and adding all the instance modifier methods,
giving users of the choice of coding in an optimized way or in a readable/manageable way.

 

[Shawn B.]

I had thought about this approach (I was doing so with the Shift operators)
but that extra jump cringes me. I shouldn't complain about 70 ms for 1
million X++'s, however, the 64-bit version of the class is 2x slower than
the others, the others are the same relative performance in every case.

I think I'll keep it as it is. I can emulate sufficiently a 500Mhz 6502 at
this rate, nothing to complain about.


Thanks,
Shawn

Hi Shawn,

I have no suggestion here. You have two choices, either keep it as is, or ditch the operators.
If you lose the operators, you'll have to have loads of method calls that changes the instance instead.
You'll lose consistency with the framework. If you suspect that oher

people will be using these classes

then you'll want to keep the operators for clarity, so people will know how to use the classes.
On the other hand, you could use both. In other words, keep the operators

in there and adding all the instance modifier methods,

 

[Shawn B.]

After further looking into the StringBuilder class, it appears mutable
because it is an array of chars treated in a similar manner to a linked
list. That would explain it. Not possible for me in these classes.


Thanks,
Shawn