我在C语言中使用系统调用(打开,读取和写入)来完成此功能,以模拟Linux系统中的“cat”功能,并且它比实际的慢...
我使用与真正的“cat”相同的缓冲区大小并使用“strace”我认为它正在进行相同数量的系统调用。但是我的“猫”的输出比真正的“猫”慢一点。
这是我的代码:
#define BUFSIZ 32768
int sysWriteBuffer(int fdout, char *buffer, ssize_t readBytes) {
ssize_t writtenBytes = 0;
while(writtenBytes < readBytes) {
writtenBytes += write(fdout,
buffer + writtenBytes, readBytes - writtenBytes);
if(writtenBytes == -1) {
return -1;
}
}
return 0;
}
int catPrint(int fdin, int fdout) {
char buffer[BUFSIZ];
ssize_t readBytes;
do {
readBytes = read(fdin, buffer, BUFSIZ);
if(readBytes == -1) {
return -1;
}
if(sysWriteBuffer(fdout, buffer, readBytes) == -1) {
return -1;
}
} while(readBytes > 0);
return 0;
}
我正在读取一个文件(我将其作为参数传递给main,我认为这里不需要代码)比我用该文件描述符调用catPrint()函数和输出描述符调用1所以它打印到标准输出。
我不明白为什么它会慢,因为我使用相同的文件进行测试,并且两者(真正的“cat”和我的)只有一个read()和一个write()用于整个文本。整个文本不应该出现在屏幕上吗?
P.S:我把它标记为作业,虽然我的问题(为什么它的速度较慢)不是作业的一部分。我只需要使用系统调用来创建一个“cat”类型的函数,这样就完成了。我只是对我的代码感兴趣,这有点慢。 问题解决了我的愚蠢:
我只是决定在同一个文件上一次又一次地调用linux的原始cat,并且我刚刚意识到它在某些时候我调用它也很慢,就像我自己一样慢。我想一切都比......好。
很抱歉浪费你的时间。
答案 0 :(得分:15)
啊,根据你的编辑,你被readahead缓冲区咬了。您无法通过运行一次来测试两个并排读取文件的程序。第一个总是慢,因为文件在磁盘上,一旦文件在内存中,第二个将运行得更快,你必须为每个创建新数据或运行一个然后运行两个,这样他们都可以获得readahead缓冲区的好处。
答案 1 :(得分:3)
也许你没有优化编译(或没有高优化设置)?
此外,您的代码会在sysWriteBuffer
等于零时调用readBytes
- 也许(部分)解释它?
您也可以内联sysWriteBuffer(通过编译器开关或手动)。
"inlining"表示将函数体复制到其调用站点,以消除调用函数的开销。有时编译器会自动执行此操作(我认为-O3在gcc中启用此优化)。您还可以使用gcc中的inline
关键字告诉编译器内联函数。如果您这样做,您的声明将如下所示:
static inline int sysWriteBuffer(int fdout, char *buffer, ssize_t readBytes) {
....
答案 2 :(得分:3)
研究mmap(2)。
你将抛弃ftell / fread的细节,但如果读取吞吐量非常重要,它将跳过一层间接。
答案 3 :(得分:2)
在不比较源代码的情况下,很难说。如果您要将您的猫与GNU cat进行比较,请记住您将几小时/几天的代码与已经发展了二十多年的代码进行比较。
您可能希望进行更全面的性能分析,从不同的设备运行具有不同输入大小的两个程序(RAM磁盘会很好)并连续多次运行。您必须尝试确定程序中的WHERE较慢。
由于cat本身非常简单(你在评论中说你已经在优化编译),我敢打赌你所观察到的性能影响不是在实际算法中,而是在程序加载时间上。如果系统二进制文件是prelinked(现在大多数发行版都很常见),你会看到它的加载速度比你自己编译的任何程序都快(直到你包含你的程序预链接)。
答案 4 :(得分:1)
多少钱?规范的猫就像
char bufr[BUFSIZ];
ssize_t len;
while((len=read(fdin, bufr, BUFSIZ)) >0)
write(fdout, bufr, len);
保存了一些说明。
答案 5 :(得分:1)
你比较两者的strace
吗?您可以尝试使用-tt
参数,以便获得系统调用的时间。