集合类型 Collections - 动态数组 Vec
在第七章我们粗略介绍了一下Vec的用法。实际上,作为Rust中一个非常重要的数据类型,熟练掌握Vec的用法能大大提升我们在Rust世界中的编码能力。
特性及声明方式
和我们之前接触到的Array不同,Vec
具有动态的添加和删除元素的能力,并且能够以O(1)
的效率进行随机访问。同时,对其尾部进行push或者pop操作的效率也是平摊O(1)
的。
同时,有一个非常重要的特性(虽然我们编程的时候大部分都不会考量它)就是,Vec的所有内容项都是生成在堆空间上的,也就是说,你可以轻易的将Vec move出一个栈而不用担心内存拷贝影响执行效率——毕竟只是拷贝的栈上的指针。
另外的就是,Vec<T>
中的泛型T
必须是Sized
的,也就是说必须在编译的时候就知道存一个内容项需要多少内存。对于那些在编译时候未知大小的项(函数类型等),我们可以用Box
将其包裹,当成一个指针。
new
我们可以用std::vec::Vec::new()
的方式来声明一个Vec。
let mut v1: Vec<i32> = Vec::new();
这里需要注意的是,new
函数并没有提供一个能显式规定其泛型类型的参数,也就是说,上面的代码能根据v1
的类型自动推导出Vec
的泛型;但是,你不能写成如下的形式:
let mut v1 = Vec::new::<i32>();
// 与之对比的,collect函数就能指定:
// let mut v2 = (0i32..5).collect::<Vec<i32>>();
这是因为这两个函数的声明形式以及实现形式,在此,我们不做深究。
宏声明
相比调用new函数,Rust提供了一种更加直观便捷的方式声明一个动态数组: vec!
宏。
let v: Vec<i32> = vec![];
// 以下语句相当于:
// let mut temp = Vec::new();
// temp.push(1);
// temp.push(2);
// temp.push(3);
// let v = temp;
let v = vec![1, 2, 3];
let v = vec![0; 10]; //注意分号,这句话声明了一个 内容为10个0的动态数组
从迭代器生成
因为Vec实现了FromIterator
这个trait,因此,借助collect,我们能将任意一个迭代器转换为Vec。
let v: Vec<_> = (1..5).collect();
访问及修改
随机访问
就像数组一样,因为Vec借助Index
和IndexMut
提供了随机访问的能力,我们通过[index]
来对其进行访问,当然,既然存在随机访问就会出现越界的问题。而在Rust中,一旦越界的后果是极其严重的,可以导致Rust当前线程panic。因此,除非你确定自己在干什么或者在for
循环中,不然我们不推荐通过下标访问。
以下是例子:
let a = vec![1, 2, 3];
assert_eq!(a[1usize], 2);
那么,Rust中有没有安全的下标访问机制呢?答案是当然有:—— .get(n: usize)
(.get_mut(n: usize)
) 函数。
对于一个数组,这个函数返回一个Option<&T>
(Option<&mut T>
),当Option==None的时候,即下标越界,其他情况下,我们能安全的获得一个Vec里面元素的引用。
let v =vec![1, 2, 3];
assert_eq!(v.get(1), Some(&2));
assert_eq!(v.get(3), None);
迭代器
对于一个可变数组,Rust提供了一种简单的遍历形式—— for 循环。
我们可以获得一个数组的引用、可变引用、所有权。
let v = vec![1, 2, 3];
for i in &v { .. } // 获得引用
for i in &mut v { .. } // 获得可变引用
for i in v { .. } // 获得所有权,注意此时Vec的属主将会被转移!!
但是,这么写很容易出现多层for
循环嵌套,因此,Vec
提供了一个into_iter()
方法,能显式地将自己转换成一个迭代器。然而迭代器怎么用呢?我们下一章将会详细说明。
push的效率研究
前面说到,Vec
有两个O(1)
的方法,分别是pop
和push
,它们分别代表着将数据从尾部弹出或者装入。理论上来说,因为Vec
是支持随机访问的,因此push
效率应该是一致的。但是实际上,因为Vec的内部存在着内存拷贝和销毁,因此,如果你想要将一个数组,从零个元素开始,一个一个的填充直到最后生成一个非常巨大的数组的话,预先为其分配内存是一个非常好的办法。
这其中,有个关键的方法是reserve。
如下代码(注意:由于SystemTime API在1.8以后才稳定, 请使用1.8.0 stable 以及以上版本的rustc编译):
use std::time;
fn push_1m(v: &mut Vec<usize>, total: usize) {
let e = time::SystemTime::now();
for i in 1..total {
v.push(i);
}
let ed = time::SystemTime::now();
println!("time spend: {:?}", ed.duration_since(e).unwrap());
}
fn main() {
let mut v: Vec<usize> = vec![];
push_1m(&mut v, 5_000_000);
let mut v: Vec<usize> = vec![];
v.reserve(5_000_000);
push_1m(&mut v, 5_000_000);
}
在笔者自己的笔记本上,编译好了debug的版本,上面的代码跑出了:
➜ debug git:(master) ✗ time ./demo
time spend: Duration { secs: 0, nanos: 368875346 }
time spend: Duration { secs: 0, nanos: 259878787 }
./demo 0.62s user 0.01s system 99% cpu 0.632 total
好像并没有太大差异?然而切换到release版本的时候:
➜ release git:(master) ✗ time ./demo
time spend: Duration { secs: 0, nanos: 53389934 }
time spend: Duration { secs: 0, nanos: 24979520 }
./demo 0.06s user 0.02s system 97% cpu 0.082 total
注意消耗的时间的位数。可见,在去除掉debug版本的调试信息之后,是否预分配内存消耗时间降低了一倍!
这样的成绩,可见,预先分配内存确实有助于提升效率。
有人可能会问了,你这样纠结这点时间,最后不也是节省在纳秒级别的么,有意义么?当然有意义。
第一,纳秒也是时间,这还是因为这个测试的Vec
只是最简单的内存结构。一旦涉及到大对象的拷贝,所花费的时间可就不一定这么少了。
第二,频繁的申请和删除堆空间,其内存一旦达到瓶颈的时候你的程序将会异常危险。
更多Vec
的操作,请参照标准库的api。