【问题标题】:Building takes long time. How fight with that?建筑需要很长时间。怎么与之抗争?
【发布时间】:2011-04-27 03:56:00
【问题描述】:

谈到编译语言(在我的例子中是 c#),我认为无论您的开发机器性能如何,这个问题都会一直存在。构建时间可能或多或少取决于具体环境,但通常足以让你的注意力从你的任务转移到其他东西,如 stackoverflow、youtube、twitter 等,这非常烦人。

由于 Java 的动态类加载,我为 Java 开发人员感到高兴,但是 .net(和其他)开发人员可以做些什么来减少构建过程的痛苦和突兀?

【问题讨论】:

  • 不要认为 Java 总是那么好。我在一家大型国际银行的 Java 商店工作,在某些情况下构建需要 3 个多小时。草并不总是更绿......
  • 任何超过 10 秒的时间,我已经忘记了我最初为什么要构建。获得更快的机器、更小的项目、更多的库等等。
  • SSD(固态磁盘)提供高达 10 倍的改进,具体取决于您的项目大小。此外,如果您对此进行改进,CPU 将不会被浪费。我知道,这是“使用更大的锤子”的方法,但它确实有效。升级后,我 1)加载 VS2008,2)加载项目 3)及时完成重建,之前的配置能够执行第 1 步和第 2 步中的一些
  • 其实我应该说“python”。大多数时候我根本不需要构建任何东西 - 当我不得不使用其中一种其他语言时,这导致我的注意力持续时间较短。
  • @Seth 在这个问题的背景下我开始学习 ruby​​)

标签: c# build-process development-environment compilation


【解决方案1】:

我们使用多种构建配置在速度和全面构建之间进行权衡。

完整的构建会做一些耗时的事情,例如 FX cop 分析、ASP.NET 编译、所有单元测试项目、实体框架视图预生成等。

“快速构建”通常只需要几秒钟,而这些只是让项目运行所需的最低限度。

开发人员在整个工作流程中根据需要在完整构建和快速构建之间切换。

【讨论】:

    【解决方案2】:

    类文件是否也必须构建?与编译时间相比,这不是将工作负载放到运行时吗?这不是真正的区别,不是吗?软件越大,构建它所需的时间就越长,这取决于机器而不是语言或框架——这是对强类型、解释字节码(或取决于语言/编译器的二进制代码)等事物的权衡) 而不是每次运行时都解释源代码(就像您使用 php 和 python 等一样)。我不认为 java 改进了很多,你必须有一个时间框架来构建你的应用程序。

    我认为与 C 和 C++ 相比,C# 和 java 在编译时间方面都得到了极大的改进。

    只是利用时间偷懒:

    source

    【讨论】:

      【解决方案3】:

      一些尝试:

      1. 对包含源代码的驱动器进行碎片整理

      2. 从病毒扫​​描程序中排除您的源代码文件夹

      3. 从 Windows 搜索索引器中排除您的源代码文件夹

      4. 禁用任何您不使用的 Visual Studio 扩展

      【讨论】:

        【解决方案4】:

        你的问题中关于一个人的注意力分散在任务之外的言论让我想起了this Joel on Software post.

        因此,投资固态磁盘(因为我假设您在开发和调试时谈论的是开发盒上的构建过程)可能会有所帮助。

        此外,让您的计算机运行得更快通常不会有什么坏处,对吧? :)

        【讨论】:

          【解决方案5】:

          除了获得更快的机器、从解决方案中删除不必要的项目等许多其他建议外,还可以考虑使用 Visual Studio 2010 + 多核机器。 VS2010 在构建时可以利用您的所有内核。查看this thread 了解更多关于如何设置的信息。

          【讨论】:

          • 我不知道 VS2010 是否利用了所有内核,但在我的机器上构建 WPF 项目的速度非常慢,即使是相对较小的项目(Core Duo 3GHz 和 4GB RAM)。
          【解决方案6】:

          您是每次都进行重建,还是将所有内容都放在同一个程序集中?我正在处理相当大的项目,我的构建时间并不长。我有几个程序集,每次对项目进行更改时我只修改一些。

          如果您发现自己到处修改程序集,您可能会尝试重构代码结构。或者也许你没有花时间做单元测试?它们不仅可以帮助您进行测试,还可以帮助您获得更好的代码结构(很难用糟糕的设计测试应用程序)。

          另一种选择是使用加速构建的工具,例如:http://www.xoreax.com/

          【讨论】:

            【解决方案7】:

            我参与过一些非常大的 C# 项目,很少看到 Debug 构建时间超过 2 分钟。

            通常会浪费时间的是静态分析(例如 fxcop)、单元测试、代码签名(如果使用代码签名服务)等。控制这些的最简单方法是将它们限制为发布版本或为“完整构建”提供单独的构建定义,并从您的调试和发布构建中排除这些步骤。

            如果这些不是您的问题,请像其他人所说的那样查看您的计算机性能。碎片、慢速构建磁盘、防病毒等。

            【讨论】:

              猜你喜欢
              • 2010-12-19
              • 2014-04-13
              • 2013-10-05
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2012-01-14
              • 2011-04-22
              • 1970-01-01
              相关资源
              最近更新 更多