Performance Degradation with AnyValue Enum

[lalitb]

As discussed in linked issue, There is a noticeable performance degradation when using the AnyValue enum compared to the Value enum. This needs to be investigated further.

Originally posted by @cijothomas in #1901 (comment)

[utpilla]

AnyValue enum has bigger variants than Value enum. To test our hypothesis of enum size affecting the creation time, I did some benchmarking for the enum creation with varying sizes of enum and I found that it takes longer to create enums as their size grows (almost linearly).

Benchmark Code

use std::collections::HashMap;

use criterion::{black_box, criterion_group, criterion_main, Criterion};

fn criterion_benchmark(c: &mut Criterion) {
    attributes_creation(c);
}

fn attributes_creation(c: &mut Criterion) {
    c.bench_function("SmallEnum", |b| {
        b.iter(|| {
            let _v = black_box(SmallEnum::Int(10));
        });
    });

    c.bench_function("MediumEnum", |b| {
        b.iter(|| {
            let _v = black_box(MediumEnum::Int(10));
        });
    });

    c.bench_function("BigEnum", |b| {
        b.iter(|| {
            let _v = black_box(BigEnum::Int(10));
        });
    });

    c.bench_function("BiggerEnum", |b| {
        b.iter(|| {
            let _v = black_box(BiggerEnum::Int(10));
        });
    });
}


// Size is 8 bytes
pub enum SmallEnum {
    /// An integer value
    Int(usize),
}

// Size is 24 bytes
pub enum MediumEnum {
    /// An integer value
    Int(usize),
    Vector(Vec<usize>),
}

// Size is 48 bytes
pub enum BigEnum {
    /// An integer value
    Int(usize),
    Map(HashMap<String, usize>),
}

// Size is 96 bytes
pub enum BiggerEnum {
    /// An integer value
    Int(usize),
    Map((HashMap<String, usize>, HashMap<String, usize>)),
}

criterion_group!(benches, criterion_benchmark);

criterion_main!(benches);

Benchmark Results:

Enum	Creation time
Small Enum (8 bytes)	167.97 ps
Medium Enum (24 bytes)	470.03 ps
Big Enum (48 bytes)	933.75 ps
Bigger Enum (96 bytes)	1.9512 ns

[lalitb]

Thanks @utpilla, this also explain the improvement observed by box'ing non-primitive/complex types within AnyValue, as that reduces the effective size of the enum. Have created #1913 as potential fix for it.