有挣扎才会有成长
这学期选了一门data mining, 第一次project挣扎map reduce, 第二次project挣扎python的速度，并且就是因为速度跑不动付出了一个late day的代价。之前的数据集都太小，就算是暴力写法只要实现了功能时间差别都在可接受范围内。
关于速度的第一次碰壁是在暑假实习的时候，hiveSQL和python的写法没有达到最优，花费了很长时间，这也确实是我的一大短板。这篇文章会结合我挣扎的事例，数据和网络上的其他资源，尽量生动一些，希望读者能在遇到相似的问题场景时候可以想起这篇文章，避免踩进这些坑里。如果读者有更高效的方法，非常欢迎指出。如果时间紧张，可以直接看每一个案例下的总结。
这篇文章会用kaggle入门比赛的house prediction的部分数据进行情景演示和分析。
数据集
大小是1460 ＊ 5
- 数据离散化。在滴滴实习的时候，需要按时间段给分成早午晚高峰，上来就把时间用了一个for循环遍历，几个if语句，然后赋值。我们来看下这个方法的速度。任务要求:新增一列，把LotArea按7000，12000切分为三部分
image.png
时间大约是0.7s，大约要写10行。
接下来我们看一下有没有更优雅，更快的方法。原则1:利用好python的原生方法
这个需求是一个映射的过程，所以我们可以直接用dataframe的map函数映射过去。
image.png
0.002s,一行代码。
总结：如果涉及到列的转化用map,如果是对自己进行处理用apply,如果是筛选，用filter。
2.计算两两之间的距离。这是一个非常常见的需求，比如我们在算knn的时候肯定少不了算pair distance。直接的暴力方法是两个for()循环。
image.png
可以看到时间是39.27s。
接下来我们来看python的原生方法：
image.png
速度是天壤之别。
3.容器的差别：需求将items装入一个容器，然后看查找速度。这里我们主要比较set和list.
list和set查找数据的速度分别是O(n)和O(1)
4.关于字典：整体操作要慢于依次遍历（比如counter统计所以行里的单词个数，用每次统计的相加要远慢于逐个单词逐个单词的更新）
