cgzipnetwcfwcf-data-services
I have an ADO.NET data service exposed by a .NET app (not IIS) which is consumed by a .NET client app. Some calls to this data service return large amounts of data.
I'd like to compress the XML data on the wire to reduce payload and improve performance. Is this possible?
These are the versions of C# known about at the time of this writing:
Dispose on IEnumerators which implemented IDisposable. A few other small features.var), and query expressionsdynamic), delegate and interface generic variance, more COM support, named arguments, tuple data type and optional parametersawait in catch and finally, extension Add methods in collection initializers.out parameter declarations, local functions, binary literals, digit separators, and arbitrary async returns.unmanaged generic type constraints. ref reassignment. Unsafe improvements: stackalloc initialization, unpinned indexed fixed buffers, custom fixed statements. Improved overloading resolution. Expression variables in initializers and queries. == and != defined for tuples. Auto-properties' backing fields can now be targeted by attributes.new expressions, target typed ?? and ?), and covariant returns. Minor features: relax ordering of ref and partial modifiers, parameter null checking, lambda discard parameters, native ints, attributes on local functions, function pointers, static lambdas, extension GetEnumerator, module initializers, and extending partial.What are the correct version numbers for C#? What came out when? Why can't I find any answers about C# 3.5?
There is no such thing as C# 3.5 - the cause of confusion here is that the C# 3.0 is present in .NET 3.5. The language and framework are versioned independently, however - as is the CLR, which is at version 2.0 for .NET 2.0 through 3.5, .NET 4 introducing CLR 4.0, service packs notwithstanding. The CLR in .NET 4.5 has various improvements, but the versioning is unclear: in some places it may be referred to as CLR 4.5 (this MSDN page used to refer to it that way, for example), but the Environment.Version property still reports 4.0.xxx.
As of May 3, 2017, the C# Language Team created a history of C# versions and features on their GitHub repository: Features Added in C# Language Versions. There is also a page that tracks upcoming and recently implemented language features.
I usually go with something like the implementation given in Josh Bloch's fabulous Effective Java. It's fast and creates a pretty good hash which is unlikely to cause collisions. Pick two different prime numbers, e.g. 17 and 23, and do:
public override int GetHashCode()
{
unchecked // Overflow is fine, just wrap
{
int hash = 17;
// Suitable nullity checks etc, of course :)
hash = hash * 23 + field1.GetHashCode();
hash = hash * 23 + field2.GetHashCode();
hash = hash * 23 + field3.GetHashCode();
return hash;
}
}
As noted in comments, you may find it's better to pick a large prime to multiply by instead. Apparently 486187739 is good... and although most examples I've seen with small numbers tend to use primes, there are at least similar algorithms where non-prime numbers are often used. In the not-quite-FNV example later, for example, I've used numbers which apparently work well - but the initial value isn't a prime. (The multiplication constant is prime though. I don't know quite how important that is.)
This is better than the common practice of XORing hashcodes for two main reasons. Suppose we have a type with two int fields:
XorHash(x, x) == XorHash(y, y) == 0 for all x, y
XorHash(x, y) == XorHash(y, x) for all x, y
By the way, the earlier algorithm is the one currently used by the C# compiler for anonymous types.
This page gives quite a few options. I think for most cases the above is "good enough" and it's incredibly easy to remember and get right. The FNV alternative is similarly simple, but uses different constants and XOR instead of ADD as a combining operation. It looks something like the code below, but the normal FNV algorithm operates on individual bytes, so this would require modifying to perform one iteration per byte, instead of per 32-bit hash value. FNV is also designed for variable lengths of data, whereas the way we're using it here is always for the same number of field values. Comments on this answer suggest that the code here doesn't actually work as well (in the sample case tested) as the addition approach above.
// Note: Not quite FNV!
public override int GetHashCode()
{
unchecked // Overflow is fine, just wrap
{
int hash = (int) 2166136261;
// Suitable nullity checks etc, of course :)
hash = (hash * 16777619) ^ field1.GetHashCode();
hash = (hash * 16777619) ^ field2.GetHashCode();
hash = (hash * 16777619) ^ field3.GetHashCode();
return hash;
}
}
Note that one thing to be aware of is that ideally you should prevent your equality-sensitive (and thus hashcode-sensitive) state from changing after adding it to a collection that depends on the hash code.
As per the documentation:
You can override GetHashCode for immutable reference types. In general, for mutable reference types, you should override GetHashCode only if:
- You can compute the hash code from fields that are not mutable; or
- You can ensure that the hash code of a mutable object does not change while the object is contained in a collection that relies on its hash code.
The link to the FNV article is broken but here is a copy in the Internet Archive: Eternally Confuzzled - The Art of Hashing
Best Answer
I assume you're hosting using WCF in your .NET "app"? If so, you would need write some custom
MessageEncoderimplementation because WCF does not provide this out of the box. Luckily there is a sample in the SDK that you can use.I actually just realized that this is only step one of two depending on whether or not your client is also WCF? While this will encode the message, it would require that your client be using a similarly configured decoder because that implementation will not set the HTTP headers that are necessary to signal that encoding has occurred to a "pure" HTTP client. So, if it's not a WCF client on the other side, in addition to encoding the message itself, you would need to use the
WebOperationContextto apply the appropriateContent-Encoding: gzipheader. Unfortunately you cannot do this within theMessageEncoderimplementation itself because it's too late in the process because by the time theMessageEncoderis asked to write the message contents the message frame, in this case the HTTP headers, has already been written. So, you would also need additional behavior, in the form of anIOperationBehavior, applied to your operations that sets the headers accordingly.