作者jacky1989 ()
看板C_and_CPP
标题[问题] 大档案读写效能改进方法
时间Sat Jul 13 13:40:00 2024
饿死抬头
我大学原本写Ｃ，但进公司後，经由前辈建议，学用Perl
同时也用Perl的强项，Regular expression(正规表示式)来改善工作效能
不过最近碰到一个问题，让我考虑是不是要回归C的怀抱
就是我工作上需要对於大型文字档做读写，从3G~10G不等
大致是这样，从文字档读进来，对特定字串做搜寻或修改，然後再写入
目前以一个字串与3G大小的档案内容做比较并读写约需38s
以两个字串比较就得花上2分钟，这效能我不太能接受，同仁也希望能改善
因此想上来问，对於大档案读写有何方法改善效能,是不是真的该回归C?
目前我查过一些资料，可以使用随机档或是binary档的方法
不过小弟我非这方面强项，所以这方法暂时先没考虑
或是我可以搜寻什麽关键字，找资料我可以自己来
我们公司是使用CentOS 7，记忆体约有1.5T
再麻烦各位了，谢谢
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 150.116.208.71 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1720849203.A.211.html
1F：推 Dracarys: 搜寻The One Billion Row Challenge 07/13 14:03
OK,感谢
2F：推 wulouise: 我觉得先改格式吧，如果多次对同一个档案seek,不如拆开 07/13 17:06
3F：→ wulouise: 你可以用C写但是瓶颈可能是io bound 07/13 17:07
4F：→ wulouise: 比方先对大档案做index或分拆，下次少搜少写赶快 07/13 17:08
5F：推 wulouise: 你可以试试看光cp要多久 07/13 17:10
大概3G大小就要花上约1-2分钟，用rsync更久.......
6F：推 kdjf: 你match的regex先给出来看看，是不是卡在regex效能 07/13 20:35
7F：→ kdjf: 除非你的程式是逻辑为主，不然你自己写的regex实作不一定能 07/13 20:36
8F：→ kdjf: 赢perl 07/13 20:37
这我清楚，不过现阶段就是要等蛮久的，所以想说挤牙膏看看有没有办法挤出更多效能
我的写法是这样
$input = "X123.X\\d+.X456.XX.RR\\d+";
$_ = "X123.X11.X456.XX.RR0 = 0.01";
while(<fid_rd>){
$tmp = $_;
if($tmp =~ /$input/i){
$tmp =~ s/0\.01/1e15/;
}
}
由於0.01与1e15都是唯一的，所以我直接写死在程式内
9F：推 LPH66: 或者换个说法:「对特定字串做搜寻或修改」是什麽样的改动? 07/13 22:59
10F：→ LPH66: 会想用 regexp 应该是「特定字串」不仅仅是固定文字 07/13 23:00
11F：→ LPH66: 那究竟是个什麽样条件的字串要改成什麽样子? 07/13 23:00
12F：→ LPH66: 然後这个「特定字串」会不会根据需求有变动可能? 怎麽变动? 07/13 23:01
13F：→ LPH66: 会说「两个字串」应该是这样的修改有两条或以上的改动规则 07/13 23:03
14F：→ LPH66: 这些规则的数量有多少? 规则型态有哪些? 07/13 23:03
15F：→ LPH66: 这些都是在考虑要不要换做法时可能会需要评估的问题 07/13 23:04
16F：推 gusion: 原字串和新字串长度一样吗？如果长度不一样，那每次写入就 07/14 00:08
17F：→ gusion: 势必要整个档案重新写入，写入的资料量就不是单纯修改後的 07/14 00:08
18F：→ gusion: 字串大小而已 07/14 00:08
只更换其中一个特定关键字，上面有
19F：推 lc85301: 这个高机率是 IO bound，不是 language 的问题 07/14 12:48
20F：推 lc85301: 如果有需要更详尽的解法，建议给一点范例测资 07/14 12:48
交叉测试过，确定是IO问题没错，不过公司硬体设备就是这样，没办法变
所以我只能研究看看是不是能靠coding来补强
21F：推 b0920075: 先用 profile tool 找热点吧 07/14 16:48
22F：推 steak5566: 前辈好坏 建议学perl 07/15 11:15
对啊！推坑完就跳槽去更好的公司了XD
23F：推 johnjohnlin: 两个字串翻倍代表你档案读两次 07/15 11:35
对的喔！
24F：推 easyman: 关键字 mmap , SIMD string lib ? 07/15 12:57
我来试试，谢谢
※ 编辑: jacky1989 (150.116.208.71 台湾), 07/15/2024 23:56:46
25F：推 alex70266: mmap或许可以，但要改内容的话可能就..嗯 07/16 12:34
26F：→ james732: 记忆体够大，不能把整个档案塞到RAM处理吗 07/16 14:10
27F：推 kdjf: 你先用dd测一下序列存取同大小的档案花多久吧？目前的写法每 07/16 20:26
28F：→ kdjf: 行会重新seek，可以看一下档案系统快取设定有没有快取到你的 07/16 20:26
29F：→ kdjf: 写入 07/16 20:26
30F：→ kdjf: 也能试看看整个档案丢到ramdisk / fs里再改的话要多久 07/16 20:29
31F：推 Killercat: 你可以先试试看简单的用mmap取代试试看 看瓶颈在哪 08/08 17:03
33F：→ Killercat: 你可以参考一下为何他可能会快一点，以及他如何profile 08/08 17:04
34F：→ Killercat: 自己土炮IO效能是一定烂的 让历史悠久的工具帮忙吧 08/08 17:04
35F：→ Killercat: Read only的use case应该可以直接套mmap不会有问题 08/08 17:05
36F：→ Killercat: 不过1.5T记忆体喔 那直接开个tmpfs在mmap吧XD 08/08 17:07
37F：推 kingofsdtw: 开档分析资料结构？ 10/31 20:11
38F：→ kingofsdtw: 那就是看你定位是读到记忆体分享 10/31 20:12
39F：→ kingofsdtw: 还是ramless定位 10/31 20:12