生成式AI领域的最新成果都在这里!抢 QCon 展区门票 了解详情
写点什么

Visual Studio 15 的内存占用探析

  • 2016-10-30
  • 本文字数:1542 字

    阅读完需:约 5 分钟

Jeff Martin 撰写了一系列关于 Visual Studio “15”性能分析的文章。在他的上一篇文章《 Visual Studio “15”的启动优化》中曾提到,微软已承诺全面提升 Visual Studio “15” IDE 的性能。本文将从内存处理的角度,探讨他们在 Technical Preview 5(TP5)中所做的提升:在主程序保留为一个 32 位进程的同时,将部分关键组件迁移到微软独有的进程。

在微软任职的 Ashok Kamath 针对这些改变在《 Visual Studio “15”的内存溢出崩溃减少优化》一文中做了更多的介绍,以便能从更全面的视角来看待这些改变。他提供了一种方法来度量微软开发团队所作出的改进。他提供了 2 个不同的指标:虚拟内存峰值 PVM(Peak Virtual Memory)和个人工作集峰值 PPWS(Peak Private Working Set)。PVM 指的是 VS15 主进程所占用的总内存数。由于主进程是 32 位的,因此它的最大值被限制为 4GB 内存。PPWS 指的是 VS15 的 devenv.exe 和相关进程所占用的物理内存数。

首先被移出 VS15 主进程的是 JavaScript 语言服务。JavaScript 语言服务提供智能提示、代码导航等功能。新的 JavaScript 服务由一个独立的 Node.js 进程协同 VS15 提供对 JavaScript 和 TypeScript 的支持。Kamath 团队通过在 VS 2015 Update 3(Visual Studio 之前的一个版本)和 VS15 Preview 5 中加载 WebSpaDurandal 方案来测量新服务的性能影响。在 VS15 Preview 5 中,PVM 占用量大约减少了 33%,但是 PPWS 的占用量减少得非常少,几乎可以忽略不计。

第二个内存优化的部分是关于调试器中的符号加载。纵观 Visual Studio 的近期发布历史,他们已经通过高侵入性地从 PDB 文件中预加载符号数据来让 C++ 调试器运行地更快。但是这个方案有一个弊端,那就是会消耗大量的内存。在 VS15 中,这个预加载功能被重写。新的预加载功能致力于只加载需要的信息而不是像之前那样“大而全”地加载。为了测量这一改进,Kamath 团队用 VS 2015 Update 3 和 VS15 Preview 5 打开 Unreal Engine 方案,并使用调试器调试 Unreal Engine 进程。结果,VS 2015 Update 3 不能执行这个操作,因为它会因为内存溢出错误而崩溃;TP5 可以执行这个操作,占用大约 3GB PVM 和大约 1.8GB PPWS。

第三个被移出主进程的是关于 Git 的组件。Visual Studio 的先前版本使用 libgit2 库,但是在 TP5 中改用 git.exe。通过使用 Chromium 包测量这个改进,发现在 TP5 中 VS 主进程占用了 0GB PVM,而 VS2015 占用了大约 300B PVM。至于 PPWS 的占用量,两者大致相当。

尽管测量工具已经提供了一些内存占用量减少的证据,但是开发者们获知这一消息后,针对微软采用的一些方案提出了许多问题。首先提到的是,更频繁的内存交换可能导致可用性下降。另外,一位名为“Syka”的评论者提出,尽管从主进程中移出部分组件会解除内存占用方面的限制,但是可能会造成潜在的性能下降。因为跨进程的进程通信相对于原来的进程内部的组件调用来说,会造成更高的通信成本。此外,一些评论者提到,Visual Studio 的真实问题并不是内存占用,而是由于主进程是 32 位而导致的寻址空间的稀缺。为此,他们再次呼吁微软能够开发 64 位版本的 Visual Studio(详情可参考《让VS 扩展支持64 位》)。

作者简介

Jeff Martin 拥有密歇根大学的 MBA 学位,曾在金融领域有所建树,但是为了紧随时代潮流,毅然投身计算机产业。他在业余时间喜欢和妻子一起旅行,阅读和编程。他刚著作了一本新书,《Visual Studio 2013 Cookbook》。可以在 Twitter 上关注他, http://twitter.com/jeffemartin

查看英文原文 Addressing Visual Studio 15’s Memory Usage


感谢冬雨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-10-30 19:002365

评论

发布
暂无评论
发现更多内容

oeasy 教您玩转 linux 010214 画面转文字 asciiview

o

高并发系列——CAS操作及CPU底层操作解析

诸葛小猿

CAS AtomicInteger compareAndSwap cmpxchg lock

如何搭建第一个 Spring 项目?

小齐本齐

spring Spring Framework Spring Bean

设计模式只是一把锤子

博文视点Broadview

读书笔记 编程 面向对象 设计模式

解Bug之路-记一次JVM堆外内存泄露Bug的查找

无毁的湖光

Linux JVM heap memory GC Linux Kenel

测试

云龙

C/C++基础之sizeof使用

C语言与CPP编程

c c++ 编程 编程语言

Flink SQL CDC 上线!我们总结了 13 条生产实践经验

Apache Flink

flink

RabbitMQ 重要概念介绍

hepingfly

Java RabbitMQ 消息队列 JMS

解决分布式session问题

架构师修行之路

分布式 架构设计 session

非科班进大厂必备算法

我是程序员小贱

面试 算法

欧洲央行近期将决定是否建立官方数字货币

CECBC

数字货币 欧央行

Js 封装:阻止频繁重复操作

程序员与厨子

一次代码评审,差点过不了试用期!

小傅哥

Java 小傅哥 代码质量 代码优化 代码规范

音乐创作者必备软件,轻松玩转原创

奈奈的杂社

音乐制作 编曲 电音 作曲 乐团

SpringBoot RabbitMQ消息队列的重试、超时、延时、死信队列

Barry的异想世界

RabbitMQ springboot 消息队列 死信队列 延时队列

为什么区块链能成为全球贸易的助推器

CECBC

区块链 金融 国际贸易

Spring事务是如何应用到你的业务场景中的?

AI乔治

Java spring 架构 微服务 springboot

有关 HashMap 面试会问的一切

小齐本齐

Java 数据结构 算法

Http请求中如何保持状态?

架构师修行之路

Spring IoC 到底是什么?

小齐本齐

spring 程序员 ioc Spring Framework Spring Bean

python——深入类和对象

菜鸟小sailor 🐕

Java String 面面观

keaper

Java string pool string

测试

STL总结与常见面试题

C语言与CPP编程

c c++ 编程 编程语言 stl

甲方日常 14

句子

Java 工作 随笔杂谈 日常

Spring 5 中文解析测试篇-WebTestClient

青年IT男

单元测试 Spring5

前端必会的七种排序算法

执鸢者

算法 大前端

大作业

Geek_2e7dd7

理财专题一

TCA

基于 Flink 的典型 ETL 场景实现方案

Apache Flink

flink

Visual Studio 15的内存占用探析_.NET_Jeff Martin_InfoQ精选文章