T********i
发帖数: 2416 | 1 牵狗搜C++ csv parser。
第一第二都是github。
https://github.com/ben-strasser/fast-cpp-csv-parser
https://github.com/vincentlaucsb/csv-parser
我相信robustness都没问题。而且各种fancy corner case都帮你搞定了。
第二个连benchmark都给你了69.9 MB in 0.33 seconds.
也就是10G大约47s。1.80GHz i7 + Toshiba XG5 SSD。
讨论：这个应该主要是I/O bound。Toshiba XG5 SSD peak sequential read可以达到2
/3GB/s。
如果你用机械HD，估计也就80-100MB/s那个样子。
另外，这个是sequential read，性能和文件大小关系不大。当然，如果是小文件，第
一遍benchmark会比第二次慢很多，因此第二次cache文件到RAM里面了。
不论如何，用上面任何一个库。你一行代码都不写，benchmark一下，应该1分钟左右完
成。AGAIN，记住SSD和mechnical HD不一样！
我不明白这么简单的事情，为什么能扯好几天的蛋？ |
T********i
发帖数: 2416 | 2 另外，澄清一下误解。
DISK I/O，不论什么介质，SSD或者机械的。都是单线程sequential最快。
你开几十个线程，并行读，肯定更慢。
尤其是机械的。乱seek，并行慢10倍都很容易。
如果你读完了CPU in memory处理很费事，可以考虑一个I/O thread分批读，发送多个
thread处理。这种情况，total threads == CPU cores是最优的。如果你CPU只有4
cores，每个2 hyper thread，那么total == 8 threads。多了的话，没用！ |
g****t
发帖数: 31659 | 3 他问的是单线程嘛。单线程的库不好找。io用fread读一块，用庫parse一下，再读再
parse就好。另外csv很trick的，就算用开源库（你找的第二个不错，visual studio也
可以用），我肯定要检查Windows 文件，unix
文件EOF EOL之类的东西的。
: 另外，澄清一下误解。
: DISK I/O，不论什么介质，SSD或者机械的。都是单线程sequential最快。
: 你开几十个线程，并行读，肯定更慢。
: 尤其是机械的。乱seek，并行慢10倍都很容易。
: 如果你读完了CPU in memory处理很费事，可以考虑一个I/O thread分批
读，发
送多个
: thread处理。这种情况，total threads == CPU cores是最优的。如果你
CPU只
有4
: cores，每个2 hyper thread，那么total == 8 threads。多了的话，没
用！
【在 T********i 的大作中提到】
: 另外，澄清一下误解。
: DISK I/O，不论什么介质，SSD或者机械的。都是单线程sequential最快。
: 你开几十个线程，并行读，肯定更慢。
: 尤其是机械的。乱seek，并行慢10倍都很容易。
: 如果你读完了CPU in memory处理很费事，可以考虑一个I/O thread分批读，发送多个
: thread处理。这种情况，total threads == CPU cores是最优的。如果你CPU只有4
: cores，每个2 hyper thread，那么total == 8 threads。多了的话，没用！
|
n******t
发帖数: 4406 | 4 說實話啊，我覺得用了這個也沒用。csv這種東西parse完了是要拿去幹別的事情的，你
覺得這麼一件事情搞不明白的，下面的事情能搞明白？
到2
【在 T********i 的大作中提到】
: 牵狗搜C++ csv parser。
: 第一第二都是github。
: https://github.com/ben-strasser/fast-cpp-csv-parser
: https://github.com/vincentlaucsb/csv-parser
: 我相信robustness都没问题。而且各种fancy corner case都帮你搞定了。
: 第二个连benchmark都给你了69.9 MB in 0.33 seconds.
: 也就是10G大约47s。1.80GHz i7 + Toshiba XG5 SSD。
: 讨论：这个应该主要是I/O bound。Toshiba XG5 SSD peak sequential read可以达到2
: /3GB/s。
: 如果你用机械HD，估计也就80-100MB/s那个样子。
|
g****t
发帖数: 31659 | 5 刷题再多，也对写个能用的Windows notepad无帮助。
: 說實話啊，我覺得用了這個也沒用。csv這種東西parse完了是要拿去幹別
的事情
的，你
: 覺得這麼一件事情搞不明白的，下面的事情能搞明白？
: 到2
【在 n******t 的大作中提到】
: 說實話啊，我覺得用了這個也沒用。csv這種東西parse完了是要拿去幹別的事情的，你
: 覺得這麼一件事情搞不明白的，下面的事情能搞明白？
:
: 到2
|
T********i
发帖数: 2416 | 6 老顾动不动就神秘化。什么EOF EOL之类。
就是Windows和DOS换行用CR+LF，C语言里面是\r\n
MAC OSX和Unix用LF，单个\n。
这些，对CSV没影响，把\r直接滤掉就好。
还有一个老顾没提，估计是不知道呵呵，那就是如果文件是Unicode，比如里面有中文
，在Window里面，文件前三个字节硬塞了EF BB BF三个字符。
这些，我假定都不是大问题。人家连整个RFC就实现了，这些应该都能搞定。否则早有
人报issue了，基本轮不到我们。退一万步讲，即使真的没搞定，改代码也就是几分钟
的事情。
至于单线程多线程，用户call API，单线程等一分钟返回，那就是单线程。里面咋实现
的管你啥事？再说了，第一个编译可以强制单线程。 |
g*******u
发帖数: 3948 | 7 不把简单问题复杂化，老顾就不能多打字了
到2
【在 T********i 的大作中提到】
: 牵狗搜C++ csv parser。
: 第一第二都是github。
: https://github.com/ben-strasser/fast-cpp-csv-parser
: https://github.com/vincentlaucsb/csv-parser
: 我相信robustness都没问题。而且各种fancy corner case都帮你搞定了。
: 第二个连benchmark都给你了69.9 MB in 0.33 seconds.
: 也就是10G大约47s。1.80GHz i7 + Toshiba XG5 SSD。
: 讨论：这个应该主要是I/O bound。Toshiba XG5 SSD peak sequential read可以达到2
: /3GB/s。
: 如果你用机械HD，估计也就80-100MB/s那个样子。
|
T********i
发帖数: 2416 | 8 这些问题，包括那个12306，其实解决方案都很boring，就是太简单！
I like simple!
而且都是小学数学就应该能搞定的！
做一个大项目，100%从底层做起，我就是能用别人10%的代码，去实现更多的功能！
大家都是聪明人，主要是越聪明的人，扯蛋越多，利益冲突越难把控！你看看小菊花谈
吐多高深？这世界上有他不知道的么？这样的，不用多，混进来一个，项目基本就毁了
。而且让你10辈子都找不出毛病在哪里？ |
T********i
发帖数: 2416 | 9 Windows Unicode那三个字节叫做Byte Order Mark (BOM)
EF BB BF
我检查了一下，这俩库，还真的都不能处理。
不过，修改一下也就是几分钟。
更何况，用户可能不需要呢？
大概率他的csv是别的软件生成的，根本没这个mark！
微软其实很多无事生非。不说也罢。
这也说明了我这些年一直强调的。只有代码可重用才靠谱。所谓的module可重用基本是
扯蛋！还有就是任何其他人的代码，不改基本不好用。 |
g****t
发帖数: 31659 | 10 包括你说的这个细节，好多细节我确实不知道。但我知道这个地方有风险。
所以要测试要查的。
csv是人人都能写的文本文件。windows文本文件和unix文本文件好多细节要处理。
end of line那个我记得是这样的，你查查看对不对：
有的windows软件写出来的csv，最后一行会把dash r，dash n里的dash r删掉。
所以古代录入实验数据的时候，csv文件最后一行要按个return是比较稳妥的办法。
另外excel，windows老的notepad写出来的csv也有问题要处理。那些更麻烦。
就不多说。这些东西不是我故意抬扛，有的硬件测试设备带的软件，出来的数据还就
是windows excel csv。
金融口的csv估计另有一对麻烦，我不熟悉就不说了。
【在 T********i 的大作中提到】
: 老顾动不动就神秘化。什么EOF EOL之类。
: 就是Windows和DOS换行用CR+LF，C语言里面是\r\n
: MAC OSX和Unix用LF，单个\n。
: 这些，对CSV没影响，把\r直接滤掉就好。
: 还有一个老顾没提，估计是不知道呵呵，那就是如果文件是Unicode，比如里面有中文
: ，在Window里面，文件前三个字节硬塞了EF BB BF三个字符。
: 这些，我假定都不是大问题。人家连整个RFC就实现了，这些应该都能搞定。否则早有
: 人报issue了，基本轮不到我们。退一万步讲，即使真的没搞定，改代码也就是几分钟
: 的事情。
: 至于单线程多线程，用户call API，单线程等一分钟返回，那就是单线程。里面咋实现
|
|
|
g****t
发帖数: 31659 | 11 你低估这个问题的复杂性了。
先不说csv的问题。文本文件：
https://latedev.wordpress.com/2012/12/04/all-about-eof/
这个我扫了一眼，可能还没有写全。
【在 g*******u 的大作中提到】
: 不把简单问题复杂化，老顾就不能多打字了
:
: 到2
|
g****t
发帖数: 31659 | 12 小心驶得万年船。
【在 T********i 的大作中提到】
: Windows Unicode那三个字节叫做Byte Order Mark (BOM)
: EF BB BF
: 我检查了一下，这俩库，还真的都不能处理。
: 不过，修改一下也就是几分钟。
: 更何况，用户可能不需要呢？
: 大概率他的csv是别的软件生成的，根本没这个mark！
: 微软其实很多无事生非。不说也罢。
: 这也说明了我这些年一直强调的。只有代码可重用才靠谱。所谓的module可重用基本是
: 扯蛋！还有就是任何其他人的代码，不改基本不好用。
|
T********i
发帖数: 2416 | 13 这个就是几分钟的问题。
我估计楼主就是一次性parse。要是我直接上库。
搜到的两种估计99%都能一次通过。
有问题再说。我估计最大的问题就是哪个windows的BOM。哪个需要改一下代码。也就几
行。
总之，就是3-10分钟的事儿。
【在 g****t 的大作中提到】
: 小心驶得万年船。
|
n******t
发帖数: 4406 | 14 小菊花可能會叫你用cdn,什麼東西之類的。
【在 T********i 的大作中提到】
: 这些问题，包括那个12306，其实解决方案都很boring，就是太简单！
: I like simple!
: 而且都是小学数学就应该能搞定的！
: 做一个大项目，100%从底层做起，我就是能用别人10%的代码，去实现更多的功能！
: 大家都是聪明人，主要是越聪明的人，扯蛋越多，利益冲突越难把控！你看看小菊花谈
: 吐多高深？这世界上有他不知道的么？这样的，不用多，混进来一个，项目基本就毁了
: 。而且让你10辈子都找不出毛病在哪里？
|
y****w
发帖数: 3747 | 15 这个说IO密集魏老师特指原始超慢方案吧。 不然怎么看也是CPU密集。
一是数据进来要parse 二是内核还得里外给
折腾。随便写一下 看看CPU是不是wait比例那么大。系统大块读文件的能力不要小瞧。 |
T********i
发帖数: 2416 | 16 这个我考虑也是欠周到。
SSD读速度大约500MB/s。NVME可以2-3GB/s。这个很容易验证。
但是他那个benchmark是1.8GHz笔记本电脑。
6core/12 thread台式机呢？32core/64 thread AMD threadripper呢？
【在 y****w 的大作中提到】
: 这个说IO密集魏老师特指原始超慢方案吧。 不然怎么看也是CPU密集。
: 一是数据进来要parse 二是内核还得里外给
: 折腾。随便写一下 看看CPU是不是wait比例那么大。系统大块读文件的能力不要小瞧。
|
