[参考译文] 编译器：TI编译器内部版本中的大失所

我怀疑一个(或两个)功能在大部分时间都占用了。  要查找该函数，请添加选项--verbose并再次生成。  您可以从编译器获得更多输出。  它在编译时打印每个函数的名称。  如果我的猜测是正确的，您将看到需要很长时间的函数的名称。  一旦您知道，下面介绍了如何提交测试案例以供进一步分析。

1. 预处理 包含有问题函数的源文件
2. 将该文件附加到您的下一篇文章中
3. 指示函数的名称
4. 显示使用的编译器版本
5. 准确显示编译器看到的所有生成选项

谢谢，此致，

-George

详细无帮助。 正如我之前所说的，它与任何特定文件无关，而是与项目中的"文件数量"有关。

确实，如果我执行完全构建(使用stall)，它将停止文件x.cpp，然后我返回并触摸文件x并执行增量构建， 则项目将快速而良好地构建。

如果执行 “Clean and Rebuild (清洁并重建)”操作，所有停止运转的情况将再次出现。  

停止位于一个文件和另一个文件的开头之间：

"../Generated/UIServer.CPP"=> UIServer：：初始(UIServer*，Const QP：：QEvt *)

"../Generated/UIServer.CPP"=> UIServer：HandleCommunication (UIServer*，Const QP：：QEvt *)

"../Generated/UIServer.CPP"==> UIServer::Enabled (UIServer*，const QP::QEvt *)

'完成的建筑：./Generated /UIServer.CPP'

'' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX     在此停转XXXXXXXXXXXXXXXXXXXXXXXXX

'正在构建文件：../Generat/RATClient.CPP'

'调用：ARM编译器'

“c:\ti/ccsv7/tools/compiler/ti-CGT-arm_vs.3.lts/bin/armcl" 16.9 -mv7m4 --code_state=16 --float_support=FPv4SPD16 -me -Ooff --include_path="C:/ti/ccsv7/tools/compiler/ti-cv-cvt_support=16 --fave/workspace 16.9 用户/common_v/workspace/workspace/workspace="include_users/f_v/f_users/fi_users/fies/fav_users/workspace/workspace_users/users/users/fi_fies/fies/fi_users/workspace_users/workspace./users/workspace_fi_users/users/workspace_f_f_/s-fi_/s-workspace./users/users/users/users/users/common_fies/

David，

以下是一些初步的想法，建议和问题。

当我们跨越一定数量的源C++文件时，我们似乎遇到了一个停顿。  编译器似乎只冻结了近5分钟！[/QUET]

遇到此问题的项目有多少个源文件？
您是否尝试过在新的CCS工作区中导入和构建项目，只是为了排除工作区本身的任何问题？

停止是否总是发生在一个源文件编译和另一个源文件编译之间？ 在每次重建过程中，是否在相同的点(即相同的源文件之间)发生？

DavidVescovi 说：

我怀疑可能只是Java VM的堆空间不足或类似情况？？？？[/QUOT]

您可以按照 本常见问题解答中的说明对Java堆设置进行实验 ，以查看它是否有任何影响。

如果上述任何建议都不能提供帮助，我们必须考虑接下来要采取的步骤。 理想情况下，我们希望能够在本地重现该问题。 您是否可以/可以与我们分享项目？ 如果没有，我必须与开发团队确认是否有特定日志可以帮助他们调查问题。

您能否建议要改变的内容？

我看到一个CCS_PROPERTIES

ccs_config.xml

ccsstudio.ini

eclipse.ini

全部位于ccsv7下的TI文件夹中

我尝试了几个模式来-Xmxx 512 m  ，但似乎没有什么区别。

扼要重述：

与CCS版本无关...在v5和7上执行相同的操作

与TI编译器版本无关 ...尝试了多个版本，包括最新版本。

另请注意：此问题正在影响我们所有的开发人员(大约20名以上)，他们使用的计算机范围从四核4.2GHz (32GB RAM)一直到2GHz (带有8 GB RAM)。

这个问题似乎只是在我们的项目中跨越了任意数量的C++文件时才出现的(据我们所能知道的)。

这个问题似乎只有在我们的项目中跨越了任意数量的C++文件时才会出现(据我们所能知道的)。

Process Explorer是最容易启动的，因为您可以看到正在运行的进程的树。

DavidVescovi 说：

我尝试了几个模式来-Xmx 512 m  ，但似乎没有什么区别。

David，

建议尝试将ccstudio.ini文件中的-Xmx参数更改为768 m。 但听起来你已经尝试过了，但没有什么不同。

请您回答这些问题吗？ 它们可能有助于提供一些额外的见解。

1)遇到此问题的项目有多少个源文件？

2)您是否尝试过在新的CCS工作区中导入和构建项目，只是为了排除工作区本身的任何问题？

3)在一个源文件编译和另一个源文件编译之间是否总是发生停顿？ 在每次重建过程中，是否在相同的点(即相同的源文件之间)发生？

4)是否可以尝试使用命令行而不是CCS GUI来构建项目？ 这有助于隔离问题的来源。 有关如何在命令行上导入和构建项目的详细信息，请参阅此页面： http://processors.wiki.ti.com/index.php/Projects_-_Command_Line_Build/Create
我建议尝试在新工作空间中导入和生成命令行，只是为了将其分开。

5)最后，您能否与我们分享项目，以便我们在当地重现问题？  

1)我必须在1号回复您  ...我有日志。

2)我很难相信我们的20位开发人员都同时存在工作空间问题。

3)否，正如我之前所说的，它根据(看起来是什么)文件的数量在两个文件之间移动。

它并不总是位于...it移动的两个相同文件之间。

我已经说过，它似乎与文件的数量有关，因为它在完成一个文件的编译和下一个文件的开始之间停顿。

[引用user="DavidVescovi)]我有一个几乎被剥离的项目，仍然存在问题。
我可以将其压缩并发送给其他人进行分析。
[/引述]

我向您发送了一个朋友请求。 接受请求后，您可以开始与我进行私人对话，并将zip文件附加到其中。 谢谢！

我看到您已进入专用频道来交换文件。 只想说，您有700多人对这条线感兴趣，请告诉我们它的最终效果如何！

谢谢

要复制此文件的文件已脱机交换。 为了方便其他人了解此主题，下面是目前为止的总结。

生成其中一个源文件时发生停顿。 我通过在禁用“并行构建”选项后构建项目来缩小此范围。  启用并行生成时，由于多个进程同时运行，因此会给人一种在源文件之间发生停顿的印象，而实际上是在编译其中一个文件时发生停顿。 这也通过选择和构建该单一源文件得到了确认。

在将其缩小为特定源文件后，我启用了--verbose编译器选项，并在命令提示符下仅生成了该单个文件。 这有助于缩小需要很长时间建立的特定功能。 在这种情况下，建议将功能分成较小的功能，这是最初的海报要查看和报告的功能。

您能告诉我们什么原因使函数编译时间过长吗？ 是否有数千条长队？ 它是否具有57个级别的嵌套"IF"？ 我相信您的许多读者都想知道如何避免这种情况发生。 我以前从未听说过这样的事情。

谢谢！

劳埃德

我们对违规函数进行了几项改进，但我相信，当我们删除   了一些内联调用并删除了头文件中出现的一些宏扩展时，这是主要的改进。

可能是每次扫描头文件时都会进行宏扩展。