在使用clang的代码完成机制时,我正在调查潜在的代码完成加速。下面描述的流程是我在Anders Bakken的rtags中找到的。
转换单元由监视文件更改的守护进程解析。这是通过调用clang_parseTranslationUnit
和相关函数(reparse*
、dispose*
)来完成的。当用户请求源文件中给定行和列的完成时,守护进程将最后保存的源文件版本和当前源文件的缓存转换单元传递给clang_codeCompleteAt
。(Clang CodeComplete docs)。
传递给clang_parseTranslationUnit
(从CompletionThread::process, line 271)的标志是CXTranslationUnit_PrecompiledPreamble|CXTranslationUnit_CacheCompletionResults|CXTranslationUnit_SkipFunctionBodes
。传递给clang_codeCompleteAt
(从CompletionThread::process, line 305)的标志是CXCodeComplete_IncludeMacros|CXCodeComplete_IncludeCodePatterns
。
对clang_codeCompleteAt
的调用非常慢-即使在完成位置是合法成员访问代码的情况下,也需要大约3-5秒来获得完成,这是clang_codeCompleteAt
文档中提到的预期用例的一个子集。按照IDE代码完成标准,这似乎太慢了。有没有办法加快速度呢?
发布于 2015-06-23 04:04:33
clang_parseTranslationUnit的问题是,预编译的前同步码在第二次被称为代码完成时没有被重用。计算预编译前同步码花费的时间超过这些时间的90%,因此您应该允许尽可能快地重用预编译前同步码。
默认情况下,它会在第三次被调用来解析/重新解析翻译单元时被重用。
看看ASTUnit.cpp中的这个变量'PreambleRebuildCounter‘。
另一个问题是此前导码保存在临时文件中。您可以将预编译的前同步码保存在内存中,而不是临时文件中。这样会更快。:)
发布于 2015-06-05 01:54:50
有时,这种大小的延迟是由于网络资源(文件搜索路径或套接字上的NFS或CIFS共享)超时造成的。在您运行的进程前面加上strace -Tf -o trace.out
,尝试监控每个系统调用完成所需的时间。查看trace.out
中尖括号中的数字,表示需要很长时间才能完成的系统调用。
您还可以监视系统调用之间的时间间隔,以查看文件的哪个处理过程花费的时间太长。要执行此操作,请在运行的进程前添加strace -rf -o trace.out
。查看每次系统调用之前的数字,以确定系统调用间隔是否较长。从这一点向后看,查找open
调用,看看哪个文件正在被处理。
如果这不起作用,您可以对您的进程执行profile操作,以查看它将大部分时间花在哪里。
https://stackoverflow.com/questions/26989374
复制相似问题