简单的说,如果你的程序是基于.net framework的托管代码的话,NGEN服务能让你的程序第二次打开的速度变快. 赶脚是非常pad化的一项服务. http://msdn.microsoft.com/zh-tw/magazine/cc163610.aspx

我的PC设备比较旧了,为了系统能流畅点,不必要的服务就不开启了.然而,服务那么多,每次重装,都要从头了解一下一边,浪费时间. 个人在网络上收集信息并结合自己的摸索,整理如下,以备查找. 服务名称  显示名称 设置状态  备注  AxInstSV  ActiveX Installer (AxInstSV)  Manual    SensrSvc  Adaptive Brightness  Disable  非触屏用户可以关了,当然有感光传感器的显示器的,也应打开,一般的显示器没有.  AeLook

本文转自:http://bbs.cfanclub.net/thread-391985-1-1.html Win7的服务,手动的一般不用管他,有些自动启动的,但对于有些用户来说是完全没用的,可以考虑禁用.Adaptive Brightness监视氛围光传感器,以检测氛围光的变化并调节显示器的亮度.如果此服务停止或被禁用,显示器亮度将不根据照明条件进行调节.该服务的默认运行方式是手动,如果你没有使用触摸屏一类的智能调节屏幕亮度的设备,该功能就可以放心禁用.Application Experience

Adaptive Brightness监视氛围光传感器,以检测氛围光的变化并调节显示器的亮度.如果此服务停止或被禁用,显示器亮度将不根据照明条件进行调节.该服务的默认运行方式是手动,如果你没有使用触摸屏一类的智能调节屏幕亮度的设备,该功能就可以放心禁用.—————— Application Experience在应用程序启动时为应用程序处理应用程序兼容性缓存请求.该服务的默认运行方式是自动,建议手动. —————— Application Information使用辅助管理权限便于交互式应用程序

windows 7已经发布有段时间了,相信很多网友都已经换上了传说中非常完美的win7系统.win7不仅继承而且还超越了vista的美观界面,性能优化方面也下足了功力.还拥有强大的win xp兼容性,这使得很多XP用户都愿意将系统升级为windows 7,它在资源利用方面优化也是可圈可点,不像VISTA,让人感觉“缓慢”和“急躁”.本文就来给大家详解下win7的进程和服务,大家可以根据自己的需求关闭服务以提高win7系统运行速度. 不建议关闭或禁用的服务  AppID Service  确定应用

win10 .Net Runtime Optimization Service占用大量CPU资源解决方法 https://blog.csdn.net/cwg2552298/article/details/83855686   最近重装了 win10,发现有个进程在空闲时占用大量CPU资源,让我可怜的电脑 不停的工作……让我感到很烦,故希望将它关闭,但是它就像个杀不死的小强,任凭 我怎么结束过几秒又自动启动了? 遂开始调查这个烦人的进程. 转到详细信息发现是 mscorsvw.exe 进程,转到服

起因是发现一个同事编写的程序运行两个月左右,占用了服务器20G左右的内存.用WinDbg查看发现存在大量的Async Pinned Handles,而它们的gcroot都来自于SocketAsyncEventArgs.下面是场景的简易模拟代码(为了说明问题添加了手动GC): ; i < ; ++i) { var endPoint = new IPEndPoint(IPAddress.Parse(host), port); var socket = new Socket(endPoint.Addr

  前文提到Windows系统启动的原理,其中加载各项系统服务是影响系统启动时间的重要因素,之前软媒在Win7之家(http://www.win7china.com/)和Vista之家(http://www.vista123.com/)上都写过类似的服务优化攻略,今天重新整理一下,列入这个开机加速全攻略里面,保持这次开机提速技术上的完整性. 1.了解 Windows 7 服务的基础知识 与Windows XP和Windows 2003才七十多个服务相比,到Windows 7时代,系统已经增加到一

原文链接地址:http://blog.csdn.net/civilman/article/details/51423972 Adaptive brightness 监视周围的光线状况来调节屏幕明暗,如果该服务被禁用,屏幕亮度将不会自动适应周围光线状况.该服务的默认运行方式是手动,如果你没有使用触摸屏一类的智能调节屏幕亮度的设备,该功能就可以放心禁用. 目标路径:\Windows\system32\svchost.exe -k LocalServiceAndNoImpersonation Appl

只要到服务里把 Microsoft .NET Framework NGEN v4.0.30319_X86 这个改成手动停止 或 禁用就可以 对vs没有影响   PS:禁了这个服务,开发wcf 在调试的时候会出错(未认证过)

原文网址:http://www.blogjava.net/sound/archive/2008/08/21/40499.html 现在的计算机图书发展的可真快,很久没去书店,昨日去了一下,真是感叹万千,很多陌生的出版社,很多陌生的作者,很多陌生的译者,书名也是越来越夸张,什么××天精通××,精通××编程, ××宝典等等,书的印刷质量真的很好,纸张的质量也是今非昔比啊,但书的内容好象却是越来越让人失望,也许是我老了,我的思想我的观念已脱离现实社会,也许是外面的世界变化得太快,我编程数月,出去一走,

在调试时会发现出于性能考虑.NET Framework dll加载的都是ngen版本,比如:System.dll,实际加载System.ni.dll. 如果希望加载非ngen版本,可以设置系统环境变量COMPLUS_ZapDisable=1.

首先放出官方MSDN的文档地址 Mpgo.exe 主要用于分析程序集启动时需要哪些东西,然后将信息反馈给NGen.exe 来更好的优化本机映像,使得应用程序启动更快,工作集缩小.准备发布时,用MPGO工具启动它,走一遍程序的常规任务.与所执行代码相关信息就会写入profile并嵌入程序集文件中. Ngen.exe 利用这些profile数据来更好地优化它生成本机映像.

最近开发的服务放到IIS上寄宿之后,遇到一些现象,比如刚部署之后,第一次启动很慢:程序放置一会儿,再次请求也会比较慢.比如第一个问题,可以解释为初次请求某一个服务的时候,需要把程序集加载到内存中可能比较慢,第二个问题有可能是IIS的线程回收机制导致放置若干长时间,空闲的进程被回收了,再次请求的话可能比较慢. 刚开始的时候没有太在意,但是随着系统的发布,这种初次请求,或者闲置若干时间后第一次请求的漫长等待使得App的体验很差,很多时候App加载好半天数据都没过来.如果前端没处理好,还会导致App的

前言 在看<CLR>的时候,作者在开篇的时候提到了NGen.exe,前面一节执行程序集的代码中提到:程序或方法执行前会执行MSCorEE.dll中的JIT函数把要执行方法的IL转换成本地的CPU指令,讲代码放在内存块中,第二次调用方法的时候,由于已对方法进行了验证和编译,所以会直接执行内存块中的代码,不需要再执行JIT函数编译了.因为在方法没调用之前都会要调用JIT函数编译,在这一节的最后作者也提到,通过实验表明,CLR的JIT编译器似乎没有使自己的应用程序达到应有的性能,然后就提到了.Net

一.JITCompiler 如你所知,JIT(just-in-time或“即时”)编译器是CLR的重要组件,它的职责是将IL转换成本地cpu指令. <<CLR via C#>>一书中在CLR的执行模型章节里有一副图形象介绍了一个方法(WriteLine)首次调用时发生的事情: JITCompiler函数被调用时,它知道要调用的是哪个方法,以及具体是什么类型定义了该方法.然后,JITCompiler会在定义该类型的程序集的元数据中查找被调用的方法的IL,接着JITCompiler验证

一.JITComplier 如你所知,JIT(just-in-time或“即时”)编译器是CLR的重要组件,它的职责是将IL转换成本地cpu指令. <<CLR via C#>>一书中在CLR的执行模型章节里有一副图形象介绍了一个方法(WriteLine)首次调用时发生的事情: JITComplier函数被调用时,它知道要调用的是哪个方法,以及具体是什么类型定义了该方法.然后,JITComplier会在定义该类型的程序集的元数据中查找被调用的方法的IL,接着JITComplier验证

简介 一时好奇心起,想一窥.Net Framework 4.0内部究竟是使用何种算法排序.以前听人说Framework内部是使用的快速排序,但究竟耳听为虚,眼见为实.主要通过JetBrains dotPeek 1.2作为工具反编译Framework的代码进行查看,也参考了其他很多资料.本人才疏学浅,其中难免存在错误,希望大家不吝指教. 数组 众所周知,数组实质上是Array类的实例.呃,要是被代表了,可以通过如下方式验证: 数组排序方法 初一看,数组的排序方法似乎很多,如下图: 但是只要我们再认

先科普一下,.Net是一个用于Windows的托管代码模型,用于高效构建具有视觉上引人注目的用户体验的应用程序.但这个模型生成的代码并非可执行代码,而是由.Net公共语言运行库环境执行的IL代码.所以,每次执行代码时,都会由.Net将IL代码翻译为机器代码.所以,效率上自然会受到一定影响.对此,微软在.Net中附带一个将IL代码转换为Native代码的工具Ngen.exe.它可以创建一份程序集文件至类似于C:\WINDOWS\assembly\NativeImages_v4.0.30319_32

转:http://www.yl1001.com/userzone.htm?doaction=article&art_id=5851381388387201 我们一般都知道,.NET Framework的GAC(global assembly cache)其实就是一个特殊的目录,如下图所示 再谈CLR:.NET Framework GAC目录构造    但是它内部到底是什么结构呢?    再谈CLR:.NET Framework GAC目录构造        很奇怪对吧?两个图完全不一样.不要惊讶