与 32 位相比，64 位 Visual Studio Code 的可量化优势是什么答案

【问题标题】：What is the quantifiable benefit of 64 bit for Visual Studio Code over 32 bit与 32 位相比，64 位 Visual Studio Code 的可量化优势是什么
【发布时间】：2017-08-21 01:16:36
【问题描述】：

我不是硬件专家，但我知道 64 位版本的 Visual Studio 问题请求已被 Microsoft 拒绝，称 64 位版本性能不佳。

我觉得两者之间的两个明显区别是代码库。有人在 1997 年开始它的生命，有人会认为这意味着 Visual Studio 方面的包袱更多，拥有非常现代的应用程序架构和代码的机会更少，这可能会使其更难，并且可能构建一些东西可以在 32 位上执行为什么不适合64位？我不知道。

另一方面，Visual Studio Code 是一个现代的 Electron 应用程序，这意味着它几乎只是编译了 HTML。 CSS 和 JavaScript。我敢打赌，制作一个 Visual Studio Code 版本几乎没有障碍，虽然性能可能不是真正引人注目的东西，但为什么不呢？

附言

我仍然想了解在性能方面可以改进哪些方面，以及开发人员是否可以忽略这种改进。您可能知道的任何其他信息或有趣的事实都会很好

【问题讨论】：

我认为有必要提及这篇博文我想你已经阅读了：blogs.msdn.microsoft.com/ricom/2016/01/04/…
我发现这个infoq.com/news/2016/01/VS-64-bit 更有用且信息量更大，我相信它可以很好地回答原始问题。

标签： performance visual-studio 64-bit visual-studio-code

【解决方案1】：

64 位 Visual Studio Code 的存在很大程度上是以下事实的副作用：Electron 的基于 Node.js- 和 Chromium 的运行时支持 32 位和 64 位架构，而不是应用程序的主要设计目标。 Microsoft 使用 Electron 开发了 VS Code，这是一个用于使用 Web 技术构建桌面应用程序的框架。

因为 Electron 已经包含两种架构（以及不同操作系统）的运行时，所以 VS Code 可以轻松提供这两个版本——Electron 从 JavaScript 代码中抽象出机器之间的差异。

相比之下，Microsoft 将大部分 Visual Studio 分发为包含机器特定指令的已编译二进制文件，而重写和维护 64 位源代码的成本在历史上超过了任何收益。一般来说，如果 64 位程序从不超过 32 位系统的限制，那么对于最终用户来说，它不会比 32 位程序快得多。 Visual Studio 的 IDE shell 没有做太多繁重的工作——典型工作流中大部分昂贵的处理是由通常支持 64 位系统的集成工具链（编译器等）执行的。

考虑到这一点，运行 64 位版本的 VS Code 所带来的任何好处都与使用 64 位 Web 浏览器所看到的类似。最重要的是，64 位版本可以处理超过 4 GB 的内存，如果我们需要同时打开很多个文件或 非常大 个文件，这可能很重要，或者如果我们使用许多 heavy 扩展。所以——对我们开发者来说最重要的是——编辑器在被滥用时不会耗尽内存。

虽然这听起来像是一份值得签署的保险单，但即使我们从未达到这些内存限制，但请记住，64 位应用程序通常比 32 位应用程序消耗更多内存。如果我们需要更小的内存占用，我们可能想要选择 32 位版本。大多数开发人员可能永远不会碰到 4 GB 的墙。

在极少数情况下，如果我们使用包装原生代码的扩展（例如为特定架构构建的 DLL），我们可能需要选择 32 位或 64 位版本。

我们在使用 64 位版本的 VSCode 时遇到的任何其他后果，无论是正面的还是负面的，都取决于 Electron 的底层运行时组件的版本以及它们所运行的操作系统。这些特征随着发展的进展而不断变化。出于这个原因，很难以一般方式说明 32 位或 64 位版本的性能优于其他版本。

例如，V8 JavaScript 引擎在历史上禁用了今天启用的 64 位系统上的一些优化。某些优化只有在操作系统为其提供便利时才可用。

Windows 上的未来 64 位版本可能会利用 address space layout randomization 来提高安全性（地址空间中的更多位会增加熵）。

对于大多数用户来说，这些细微差别并不重要。选择与您的系统架构相匹配的版本，并仅在遇到问题时才保留切换。编辑器的更新将继续为其底层组件带来优化。如果资源使用是大问题，您可能一开始就不想使用 GUI 编辑器。

【讨论】：

【解决方案2】：

我在 Windows 上工作不多，但与 x86、x64 和 ARM（32 位和 64 位指令集大小）处理器进行了交互。根据我的经验，在以 64 位格式编写代码之前，我们想：我们真的需要 64 位大小的指令吗？如果我们的操作可以在 32 位内执行，那我们为什么还需要另外的 32 位呢？

可以这样想：您有一个具有 64 位地址和 64 位数据总线以及 64 位大小寄存器的处理器。几乎所有程序指令都需要最多 32 位。你会怎么做？好吧，我认为现在有两种方法：

创建 64 位版本的程序并在 64 位处理器上运行所有 32 位指令。（在每个指令周期中浪费 32 位或您的处理器，并用提前 4 个字节的地址填充程序计数器）。您原本可以在 256 MB RAM 中执行的应用程序/程序现在需要 512 MB，因此在 RAM 上运行的其他程序或进程将受到影响。
将程序格式保持为 32 位，并将 2 条 32 位指令组合到您的 64 位处理器中执行。

显然，第二种方法在资源相同的情况下运行速度更快。

但是是的，如果您的程序包含更多真正 64 位大小的指令；例如。处理 4K 视频（在 64 位处理器和 64 位指令集上更好）或执行精度高达 15 位十进制的浮点运算等。然后，最好创建 64 位程序文件。

长话短说：尝试编写紧凑的软件并尽可能利用硬件。

到目前为止，我读到了Here、Here和Here；我开始知道 VS 的大多数组件只需要 32 位指令大小。

希望它能解释。

谢谢

【讨论】：

除了没有真正回答这个问题之外，这个答案还会传播错误信息（我不知道谁认为它值得赏金）：x86 上的 64 位与 32 位（我相信对于ARM）与指令大小几乎没有关系（x86 指令无论如何都具有可变长度） - 它是指针大小的变化。到目前为止，我还没有看到一个应用程序在为 x64 编译时内存消耗或平均指令长度几乎是 x86 模式下的两倍。（不要让我开始讨论浮点部分）
Floating Points Operations with up to 15 decimal digit precision 与 64 位指令无关。 x86 也可以，x86 也支持 SIMD 指令。 32 位 x86 和 32 位 ARM 的主要缺点是较小的地址范围和较小的寄存器数量。而且您错误地将 32 位和 64 位识别为指令大小，这是严重错误的
which could have been executed in 256 MB of RAM now requires 512 MB 是另一个serious misinformation。除了指针和 long 或 long long 之外，64 位程序中的类型大小仍然相同，因此除非您使用大量指针，否则大小的增加是最小的。 Keep the program format to 32-bit and combine 2 32-bit instructions to be pushed into your 64-bit processor 如果您需要这样做，那么 SIMD 会更好。您可以在单个 AVX 指令中同时对 8 个 32 位值进行操作，在 AVX512 上可以同时对 16 个值进行操作

【解决方案3】：

4 年后的 2021 年，您现在拥有：

“Microsoft's Visual Studio 2022 is moving to 64-bit”来自Mary Jo Foley

它引用了开发部门产品 CVP Amanda Silver 的官方出版物“Visual Studio 2022”

Visual Studio 2022 是 64 位

Visual Studio 2022 将是一个 64 位应用程序，不再局限于 devenv.exe 主进程中的 ~4gb 内存。借助 Windows 上的 64 位 Visual Studio，即使是最大和最复杂的解决方案，您也可以打开、编辑、运行和调试，而不会耗尽内存。

虽然 Visual Studio 是 64 位，但这不会改变您使用 Visual Studio 构建的应用程序的类型或位数。 Visual Studio 将继续成为构建 32 位应用程序的绝佳工具。

我发现观看 Visual Studio 扩展以使用 64 位进程可用的额外内存的视频真的很令人满意，因为它打开了一个包含 1,600 个项目和约 300k 文件的解决方案。
这是为了不再出现内存不足的异常。 ?

【讨论】：