我有下一个so文件/UNI/System/Libs/libmbedcrypto.so.3目录。当我启动我的应用程序时,使用libmbedcrypto.so.3和斯特雷斯我懂了:
open("/UNI/System/Libs/tls/v7l/neon/vfp/libmbedcrypto.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/UNI/System/Libs/tls/v7l/neon/vfp", 0x7ef80610) = -1 ENOENT (No such file or directory)
open("/UNI/System/Libs/tls/v7l/neon/libmbedcrypto.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/UNI/System/Libs/tls/v7l/neon", 0x7ef80610) = -1 ENOENT (No such file or directory)
open("/UNI/System/Libs/tls/v7l/vfp/libmbedcrypto.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/UNI/System/Libs/tls/v7l/vfp", 0x7ef80610) = -1 ENOENT (No such file or directory)
open("/UNI/System/Libs/tls/v7l/libmbedcrypto.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
//... more stat64 & open
open("/UNI/System/Libs/libmbedcrypto.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/UNI/System/Libs", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
如何摆脱所有 open 和 stat64 调用?
答案1
这个是正常的。实际上,如果不从头开始用汇编重写程序,或者编写自己的 C 库来配合它,则实际上无法摆脱这个问题。这几乎是任何程序的标准。说真的,您不需要优化像这样无关紧要的东西。尝试访问不存在的文件所浪费的时间可以忽略不计,正如您在下面的 系统调用跟踪中所看到的true
,该程序设计为仅从嵌入式系统返回 0:
root@UP-1044:~# strace -T -e trace=open true
open("/tmp/t/usr/lib/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000643>
open("/tmp/t/lib/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000861>
open("/lib/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 <0.000208>
+++ exited with 0 +++
每个系统调用浪费的时间似乎不到一毫秒!