1. 

最近在研究在两种不同的场景下（分别是Unix Tools和Apache Flink），分析网络跟踪文件（例如，.pcap文件）性能的区别。最简单也是最直观的比较方法就是比较在这两种环境中，处理相同的.pcap文件所需要的时间长短。想着写个小脚本应该分分钟搞定，结果在计算时长的时候出现了问题：

#!/bin/bash

START_TIME=$(date +%s.%N)

do something 

END_TIME=$(date +%s.%N)

ELAPSED_TIME=$((END_TIME - START_TIME))

echo "Runtime: $ELAPSED_TIME seconds"

此时，会抛出Illegal number的错误! 查了一下Shell本身不支持浮点运算，需要借助一个小工具bc，如果manual page看起来比较烦的话，这个tutorial比较简单直观。总的来说大概用法就是：

result=$(echo “options; operation” | bc [options])

于是，ELAPSED_TIME=$((END_TIME - START_TIME))就变成了

ELAPSED_TIME=$(echo "$END_TIME - $START_TIME" | bc )

别忘了变量前的“$”。

2.

小脚本终于跑了起来，分析一个大小为1 GB的.pcap文件大约耗时10 sec，具体统计什么这里就不说了，也没啥用。然而以上都是我在OS X中的Linux虚拟机上搞定的，Apache Flink的环境之前是在OS X上搭建的，所以脚本还是要在OS X上跑才行，而且目前也不知道虚拟机的性能会不会对结论的分析有什么影响。总而言之就是我把脚本在OS X的终端里运行了一下，发生了一个事情——Illegal character: N

这真的让我不太能理解，意思就是date +%s.%N中的%N在OS X下是不支持的（到现在不明白是为什么）。StackExchange上也有类似的问题，于是在上面找到了一个取巧的解决办法：

python -c 'import time; print time.time()'

所以，

START_TIME=$(python -c 'import time; print time.time()')

对于END_TIME同理，问题解决。（在测试的时候发现echo "$START_TIME"精度很高，做过运算之后精度只保留到小数点后两位，不知道原因，明天研究下。再次测试，发现是自己搞错了，python直接输出精度也为0.01s。）

3.

在OS X和Linux虚拟机中对同一个.pcap文件进行分析，OS X所用时间为20 sec左右，为Linux下的2倍，待研究。