potential performance issue in List

[cardoe]

So I'm following your examples and I notice in your main loop you create a new Group with new List's for each iteration. Looking at the code behind this at https://github.com/fdehau/tui-rs/blob/master/src/widgets/list.rs#L14 shows that List has a Vec inside of it. While all the items are references you'll still be allocating a Vec for the entire thing. Looking at how its then used is to iterate over the items so you could probably come up with a custom iterator type that could take in. Looking further at the List example, you collect() to a Vec and then pass the slice in since List.items() takes a slice. It then turns around an collect()'s to a Vec again so you're taking the allocation performance hit twice.

Another idea would be to take the style independently of the data, both as IntoIterator Then you could use Iterator.zip() to combine the two. You could alternatively create a type like

pub enum Item<'s> {
    Data(::std::fmt::Display), // allows any type that can be displayed to be used as input (so `String` and `&str` still work)
    StyledData(::std::fmt::Display, &'s ::tui::style::Style),
}

Then List.items() could have a signature like:

pub fn items<L: IntoIterator<Item=Item>(&'a mut self, items: L) -> &mut List<'a>

and you could just store the iterator inside of List instead collecting to a Vec. Then when draw() ran it would just work with that iterator.

[cardoe]

I should mention that Iterator.zip() doesn't work if the style iterator has less items than the data iterator because zip() stops when any of the iterators run out of data. So people would be confused why their data was being truncated.

[fdehau]

Hi, there are several valid points here. First of all, there are certainly a lot of places in the code where there is room for improvements regarding both the API exposed to the caller and the performance.

I took the liberty to implement your ideas in a dedicated branch #11. The major change required for this to work is to update the Widget signature. Indeed, until now the draw call was done using a simple & to the widget. Consuming the iterator inside the draw call would then require &mut if I'm not mistaken. This change the behavior of the widget that should now be seen as a "consumable" object. However, this does not appear to me as problem since it was one of the goals of the library anyway.

I would appreciate your feedback on this if you have some time :)

[cardoe]

Looks good. Sorry for the delay in looking at it. There were some other changes to the API so that delayed me a bit from trying it out. I like it.