饿死抬头
我大学原本写Ｃ，但进公司后，经由前辈建议，学用Perl
同时也用Perl的强项，Regular expression(正规表示式)来改善工作效能
不过最近碰到一个问题，让我考虑是不是要回归C的怀抱
就是我工作上需要对于大型文字档做读写，从3G~10G不等
大致是这样，从文字档读进来，对特定字串做搜寻或修改，然后再写入
目前以一个字串与3G大小的档案内容做比较并读写约需38s
以两个字串比较就得花上2分钟，这效能我不太能接受，同仁也希望能改善
因此想上来问，对于大档案读写有何方法改善效能,是不是真的该回归C?
目前我查过一些资料，可以使用随机档或是binary档的方法
不过小弟我非这方面强项，所以这方法暂时先没考虑
或是我可以搜寻什么关键字，找资料我可以自己来
我们公司是使用CentOS 7，内存约有1.5T
再麻烦各位了，谢谢

搜寻The One Billion Row Challenge

我觉得先改格式吧，如果多次对同一个档案seek,不如拆开你可以用C写但是瓶颈可能是io bound比方先对大档案做index或分拆，下次少搜少写赶快你可以试试看光cp要多久

你match的regex先给出来看看，是不是卡在regex效能除非你的程式是逻辑为主，不然你自己写的regex实作不一定能赢perl

或者换个说法:“对特定字串做搜寻或修改”是什么样的改动?会想用 regexp 应该是“特定字串”不仅仅是固定文字那究竟是个什么样条件的字串要改成什么样子?然后这个“特定字串”会不会根据需求有变动可能? 怎么变动?会说“两个字串”应该是这样的修改有两条或以上的改动规则这些规则的数量有多少? 规则型态有哪些?这些都是在考虑要不要换做法时可能会需要评估的问题

原字串和新字串长度一样吗？如果长度不一样，那每次写入就势必要整个档案重新写入，写入的资料量就不是单纯修改后的字串大小而已

这个高机率是 IO bound，不是 language 的问题如果有需要更详尽的解法，建议给一点范例测资

先用 profile tool 找热点吧

前辈好坏 建议学perl

两个字串翻倍代表你档案读两次

关键字 mmap , SIMD string lib ?

mmap或许可以，但要改内容的话可能就..嗯

内存够大，不能把整个档案塞到RAM处理吗

你先用dd测一下序列存取同大小的档案花多久吧？目前的写法每行会重新seek，可以看一下档案系统快取设定有没有快取到你的写入也能试看看整个档案丢到ramdisk / fs里再改的话要多久

你可以先试试看简单的用mmap取代试试看 看瓶颈在哪https://nieyong.github.io/wiki_cpu/mmap详解.html你可以参考一下为何他可能会快一点，以及他如何profile自己土炮IO效能是一定烂的 让历史悠久的工具帮忙吧Read only的use case应该可以直接套mmap不会有问题不过1.5T内存喔 那直接开个tmpfs在mmap吧XD

开档分析资料结构？那就是看你定位是读到内存分享还是ramless定位