问题标签 [build-time]

每次对代码进行任何更改时，我的构建时间都很慢。我尝试使用时序摘要进行构建，这是来自 Report Navigator 的报告-

具有 409 个任务的 CompileC 需要 134.55 秒，这是可以理解的，但我不确定 Ld（1 个任务）是什么意思，这需要将近 2 分钟。

这是什么？为什么要花这么多时间？我怎样才能在时间上改进它？

Recently I am trying to optimize the performance of a web app(React). Assuming it is somewhat heavy as it consists of Code editors, Firebase, SQL, AWS SDK, etc. So I integrated react-loadable which will lazy load the components, After that, I got this Javascript heap out of memory issue.

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory in React

After some research(From a friend), I came to know that If we keep too many lazy loadings webpack will try to bundle them parallelly It might be the cause to get a Javascript heap memory issue, To confirm that I removed all Lazy loading routes in my App and built. Now build is successful. Later as suggested by the community I increased Node heap space size and got the below insights

First I increased it to 8 GB(8192) then build is success I got build time of around 72 mins, From next time onwards I am getting around 20 mins. Then I decreased heap memory size to 4 GB(4096) and getting build success it is around 15 - 20 mins. System configuration is 2vCPU, 16GB RAM(AWS EC2 Instance r5a.large).

Next, I kept build in another system (Mac book pro, i5, 8 GB RAM, 4 Cores) Now it took 30 mins, Second time it took 20 mins

So from these data points, I got a couple of questions

1. Do we need to keep increasing heap space whenever we add some code? If yes what would be the average heap memory size in the community
2. What would be the usual configuration for build systems for these kinds of heavy apps, Why because now I am not sure whether to increase the number of cores or RAM or Heap space or Altogether something to do with our app code.
3. Do webpack provide any kind of solutions to avoid heap memory issue like limiting parallel processes, or any plugins?
4. If at all it is related with our App code, Is there any standard process to debug where it is taking memory and to optimize based on that

PS : Some people suggested to keep GENERATE_SOUCREMAP=false it got worked but we need source maps as they will be helpful in debugging production issues

我有一个巨大的 swift 项目，它有 70 多个故事板和 1269 个 XIB 和 14 个 compile swiftsources。它需要 16 到 35 分钟。正如我所看到的，大部分编译时间是由于故事板和 XIB 造成的。

我已经完成了所有的优化。

• 禁用 DSYM
• 优化级别是最快的。
• 尝试博客中提到的所有内容 -> https://www.avanderlee.com/optimization/analysing-build-performance-xcode/

任何人都可以建议我如何优化编译时间。

我正在分享构建时间摘要。

Flutter/Dart 是否支持多核编译？有人说飞镖是单芯的，不能

我用 Next.JS 制作了简单的静态电子商务应用程序。对于我的产品页面，我获取了一些数据字符串（非常少）。当我构建我的应用程序时，会收到以毫秒为单位的黄色和红色时间的模棱两可的结果输出（在下面固定图片）。

我的代码，例如每个产品页面的代码非常简单（固定在下面）。

为什么收到的时间看起来如此糟糕？需要我修复一些东西还是一切都好？在 next.js 的早期版本中，没有这样的时间标记。

我目前正在研究构建时间优化。我将这两行添加到“Other swift flags”调试选项中。

在一个干净的项目构建之后，我看到一些行多次发出警告。这些警告是否来自多次类型检查？

如果我只是: UIColor在定义之后添加，它可以解决吗？

根据通过减少动态调度提高性能，添加'final'关键字通过减少动态调度来提高运行时性能。

我想知道添加“final”关键字是否也会提高编译时间。

在一些文章中阅读了这样的观点，但我不清楚。我对其进行了测试，在我看来“最终”不会影响编译时间。

全部，

我有一个正在尝试在主机和 VirtualBox 客户端上构建的软件。

两台机器都使用相同的 RHEL7 操作系统和完全相同的 Makefile 集。

但是，主机上的构建时间比 VM 上的要快得多。

有没有办法改善构建时间，使其至少可以与主机相媲美？

蒂亚！！