TLS: Is Integrity assured when using NULL cipher In specific implementation we're using TLS 1.0, open ssl 0.9.8 but i'm referring to RFC 5246.  

For performance reasons, I'm being asked if we can use TLS without encryption.  The hope is that the perfomance cost of using TLS will be less.  The implementation will retain authentication and integrity of communication, but there will be no confidentiality.

The RFC does seem to say in Appendix C that where we see 'SHA' in a cipher suite we should understand HMAC-SHA1.  So I'd interpret the NULL_SHA in e,g, TLS_RSA_WITH_NULL_SHA as HMAC-SHA1 rather than a digest.  In Section 6.2.3.1 we see that even with a NULL cipher a mac can be calculated.  So in theory we can get integrity from TLS without encryption.

However, nobody seems to be using TLS this way, existing TLS tools (e.g. socat, openssl in default configurations) do not seem to want to negotiate null ciphers, 

So my questions


Can TLS assure authentication and integrity with a NULL cipher ?  Is this a reasonable optimisation to make, it seems to hold water but i'm not confident..
What is this optimisation likely to be worth ?  The SHA must still be computed and HMAC'd even if AES-CBC is no longer calculated.  I'm not sure how SHA compares to AES, can someone estimate what % reduction in operations there will be to calculate TLSCiphertext ?  e.g could be we expect a 50% reduction in an SSL_write / SSL_read comapred to a TLS session with AES 256 encryption


Then some less important questions 


the cipher suites in the RFC dont include a NULL cipher is the
NULL cipher  e.g. there's no DHE_RSA_NULL_SHA.  Openssl headers e.g. tls1.h does provide for a lot of cipher suites with NULL ciphers which dont figure in the RFC.  However, they dont get built into the configuration on my platform which may indicate this is not a normal things to use.  Similarly tools like socat dont seem to negotiate cipher suites with null ciphers..  So I'm wondering if interoperability wise this kind of optimisation is thin ice even if the eco-system is partly controlled.
There's a load of stuff that doesnt get defined in the RFC, like what the possible values are for SecurityParameters.mac_algorithm, validating the MAC on incoming message.  People implementing TLS have a more detailed standard or am i missing something ?
To answer your main question. 
Yes, NULL ciphersuites do provide authenticity and integrity checks but not confidentiality for the TLS traffic.

There is still a specified key exchange algorithm (e.g. RSA) for the TLS handshake protocol. The client will generate a pre-master secret and encrypt it with the server's public key for server authentication.
The session key is then derived and the MAC keys are generated from it. Authentication of messages is provided by demostrating knowledge of the MAC keys.

However, the toolkit Openssl warns that NULL ciphersuites offer no encryption at all and are a security risk. They are disabled unless explicitly included.

RFC 4785 classifies them as authentication-only ciphersuites (with no encryption).
Not sure about the your other question.