archshift / dynstack Goto Github PK

This test compiles and runs just fine:

#[test]
fn test_non_dyn() {
    let mut stack: DynStack<u8> = DynStack::new();
    for _ in 0..15 { dyn_push!(stack, 5u8); }
    let x = stack[14];
    println!("{:?}", x);
}

...but I'm quite sure it does dumb things internally, by composing and decomposing fat pointers for things where there are no fat pointers?

Hi, can you comment in detail the logic in the grow method regarding the memory alignment aspect, I'm learning the code and I can't really understand the logic.

DynStack does not auto-implement Send and Sync because it has a *mut u8 pointer. I’m like 80% sure it is Send and Sync after quickly perusing the code and have added a wrapper in my codebase that unsafely implements Send and Sync.

Is it safe to implement Send and Sync for DynStack?

Would you be open to a PR adding support for a heapless version behind an alloc feature flag, using heapless::Vec?

If this is even possible, but i can't see why not.

It would be nice to have DynStack::clear() and/or DynStack::drain() (without arguments) methods.

I use DynStack with some code that expects an ExactSizeIterator. I’ve added a wrapper in my codebase to implement that trait, but it would be cool if an ExactSizeIterator implementation were upstreamed.

struct DynStackIter<'a, T: 'a + ?Sized> {
    len: usize,
    n: usize,
    iter: dynstack::DynStackIter<'a, T>,
}

impl<'a, T: 'a + ?Sized> DynStackIter<'a, T> {
    #[inline]
    fn new(dynstack: &'a DynStack<T>) -> Self {
        DynStackIter {
            len: dynstack.len(),
            n: 0,
            iter: dynstack.iter(),
        }
    }
}

impl<'a, T: 'a + ?Sized> Iterator for DynStackIter<'a, T> {
    type Item = &'a T;

    #[inline]
    fn next(&mut self) -> Option<Self::Item> {
        let item = self.iter.next();
        if item.is_some() {
            self.n += 1;
        }
        item
    }

    #[inline]
    fn size_hint(&self) -> (usize, Option<usize>) {
        (self.len - self.n, Some(self.len - self.n))
    }
}

impl<'a, T: 'a + ?Sized> ExactSizeIterator for DynStackIter<'a, T> {
    #[inline]
    fn len(&self) -> usize {
        self.len - self.n
    }
}

According to crates.io this crate is 10.11 MiB large for version 0.2.0. I thought that was a bit large for what it did. So I downloaded the package directly from crates.io (with cargo-clone). It contains the files vgcore.24209, vgcore.826, vgcore.894 and vgcore.978 which are 27-31 MiB each when unpacked 😓 Compare with version 0.1.1 which is just 5.21 kiB.

Cargo is dangerous, just includes anything you happen to have laying around in the folder when publishing. You might want to consider adding either an exclude field to Cargo.toml excluding the huge files. Or maybe an include field specifying exactly what you want to include instead.

fn access_native(b: &mut Bencher) {
    let mut stack = Vec::<Box<dyn Display>>::new();
    for _ in 0..1000 {
        stack.push(Box::new(black_box(0xF00BAAusize)));
    }
    b.iter(|| {
        let stack = black_box(&stack);
        for i in stack {
            black_box(i);
        }
    });
}

fn access_dynstack(b: &mut Bencher) {
    let mut stack = DynStack::<dyn Display>::new();
    for _ in 0..1000 {
        dyn_push!(stack, black_box(0xF00BAAusize));
    }
    b.iter(|| {
        let stack = black_box(&stack);
        for i in stack {
            black_box(i);
        }
    });
}

Result:

access_native           time:   [315.01 ns 317.38 ns 320.12 ns]                               
Found 3 outliers among 100 measurements (3.00%)
  2 (2.00%) high mild
  1 (1.00%) high severe

access_dynstack         time:   [1.1576 us 1.1643 us 1.1717 us]                                
Found 7 outliers among 100 measurements (7.00%)
  7 (7.00%) high mild