efficient way to convert 16 bit value to 8 bit value

you can use the bit-masking concept.
Like this,

uint16_t val = 0xABCD;
uint8_t vr  = (uint8_t) (val & 0x00FF);

Or this can also be done by simply explicit type casting, as an 8-bit integer only carries LBS 8-bits from 16-bits value, & discards the remaining MSB 8-bits (by default, when assigns a larger value).

You can do as below:

uint16_t val = 0xABCD;
uint8_t vr = val & 0x00FF;    // Bitwise AND Operation

Using this bitwise operation you will get 8 bits of LSB

While both answers are correct, the bit masking here is completely redundant. It happens implicitly when converting to uint8_t. Without exactly sized integer types (and, speaking of performance, you should consider that, because performance is in general best when using the native word size of the machine), this would be different:

unsigned int val = 0xabcd;
unsigned int vr = val & 0xff;
assert(vr == 0xcd);

But when you really need to have these exactly sized type, the best code is IMHO

uint16_t val = 0xabcd;
uint8_t vr = (uint8_t) val;

The explicit cast is here to document the intention! Without it, a good compiler will warn you about the implicit conversion possibly losing information (and you should always enable compiler warnings, e.g. for gcc -Wall -Wextra -pedantic, to catch cases where you do such a conversion by accident).

The performance of all variants using the exactly sized types should be the same, because a decent compiler will emit the same code for all of them. The version using just unsigned int might perform a bit better.

[edit]: As you're asking about memory performance, too: it is unlikely that you gain something by using uint8_t because some architectures require values smaller than the native word size to be aligned to word boundaries. If they don't require it, it might still be faster to have them aligned, so the compiler might decide to do so. That just introduces unused padding bytes. With gcc, you can use the option -Os to optimize for size and as x86 architecture is byte-addressable, this may result in uint8_t being used without padding on a PC, but consequently with lower speed. Most of the time, speed vs memory is a tradeoff, you can have either one or the other.