NGen并不能提升代码执行效率
作者:V君 发布于:2015-8-23 21:46 Sunday 分类:折腾手记
TL;DR: 看这里
实际上NGen.exe仅仅是加快应用程序的启动速度,执行时的性能并不比JITCompiler编译的代码快。主要原因是,编译代码时, NGen无法像JIT编译器那样对最终的执行环境作出许多假设,这会造成NGen.exe产生较差的代码。例如, NGen不能优化一些CPU指令, 对静态字段的访问需要间接的操作而不能直接访问,因为静态字段实际的地址需要在运行时刻才能知道。NGen到处插入代码来调用类的构造函数,因为它不知道代码执行的次序,不知道类的构造函数是否已经被调用。
听我扯扯:
一直用着SevenZipSharp(7z#), 这货相当方便, 然而现在我想设计自己的压缩归档,
需要选择压缩算法纯粹的对数据块进行压缩,
然而7z#似乎没有提供这样的接口, 算法的实现又在本地的7z.dll里...
最重要的是不跨平台, linux 没法用.(尽管7z#似乎在出mono版本, 但貌似已经熄火两年...)
于是又找到了个纯托管的实现 -- SharpCompress .
嗯嗯 这货很好的实现了各种算法的纯粹压缩流,
有 LZMA, LZMA2 (仅解压) ,Gzip, Bzip2, Deflate, PPMd .
在我设计的压缩归档里面,
首先将要压缩的数据挨个调用这些算法的极限压缩, 选择最高压缩比的算法,
以一个字节标识到压缩后数据块前面,
如果所有的算法输出都比原始数据大, 那么直接存储, 数据块前面的标识会注明
跑了一遍下来
Ppmd: 3,404
Deflate: 2,160
Store: 1,996
Lzma: 393
BZip2: 595
--------------
Total: 8,548
发现PPMd算法被使用次数最多, 然而PPMd每次执行都时间几乎都在秒级以上
欲让它执行得快一点. 于是想起JIT这回事,
咕狗搜索 Force JIT 找到 NGen 试着产生 SharpCompress 的 ni.dll
用 procexp 查看确实被加载后, 对压缩调用计时.
然并卵, 速度根本没有提升嘛! 更要命的是解压反而比压缩慢, 这是闹哪样?
接着查 NGen 性能, 这时才明白原来根本就是用错东西了...
打一下自己的脸, 找C或++的实现, 然后做个C++/CLI或者导出函数来pinvoke吧.
(我大mono可是支持pinvoke的哟)
使用TcpView和ProcMon高效地诊断应用程序故障
作者:V君 发布于:2015-8-17 13:28 Monday 分类:填坑经验
收到通知说咱们的软件在客户的电脑上不工作, 于是通过远程协助到客户的电脑上做诊断.
咱们的软件分为一个 Winform 配置界面和一个 Windows 服务.
情况是这样:
通过配置界面输入参数, 然后启动服务开始工作.
然而似乎配置不生效 -- 使用TcpView看到服务连接目标是默认值而不是配置文件指定的
另外日志文件也一点都不产生.
诊断及修正:
打开ProcMon, 把服务进程名添加到筛选器, 开始观察.
找配置文件以及日志的路径监视结果, 发现拒绝访问.
嗯 马丹 去配置文件目录一看, 只有Administrator...
修正权限让服务进程能访问文件.
重新启动服务, 这下问题解决 -- 服务进程已经按照配置的参数连接到目标
日志文件也出来了. 乂目
总结:
我大 Sysinternals 棒棒哒!
(文中的两个软件都是这群人整出来的)
吐槽: 企鹅远程太难用了...
标签: 软件开发 调试技术 软件故障诊断 Sysinternals
巧用自定义协议之跨浏览器实现网页调用本地票据打印机
作者:V君 发布于:2015-8-11 0:25 Tuesday 分类:挖坑经验
TL;DR:
1) 注册自定义协议
2) 实现处理程序
系统会把整个URL当成参数传递到你的程序, 切掉协议头(xxxx://)就可以吃了
用参数调用票据打印机
3) 从网页调用这个协议
推荐使用js设置隐藏iframe的src指向协议连接
听我扯扯:
使用Windbg分析转储来定位高CPU占用的C#代码
作者:V君 发布于:2015-8-6 14:51 Thursday 分类:填坑经验
今天运维告诉我服务器上出现使用大量 CPU 的进程.
要想定位/调优必须知道这些 CPU 处理量都用去做啥然后才能动刀子.
生产环境不能附加调试, 只能绕点弯路.
服务器是Win2003 x64
当时马上就想起 Procexp 能查看线程的 CPU 使用量, 运气好还能看到本地映像的调用堆栈.
不过这次运气并不太好, 调用堆栈只能看到 kernel32.dll , 之后啥都,看不到..
于是找找看有没有专门的 .net dump / 堆栈查看工具.
找到了Managed Stack Explorer/CLR Stack Explorer
前者只能查看32位进程, 放到服务器上运行啥也刷不出
后者在工作机上能刷出所有进程,还能标出是不是64位, 然而在服务器上也是啥都刷不出...
算了还是请出高大上的 WinDbg 吧. 让运维用 Procexp 做了个 mini Dump.
在用 WinDbg 打开 dmp 文件, 载入 sosex , 呃, 提示需要完整内存转储.
好吧于是做了个了个完整内存转储 -- 1G大的dmp文件..
输入 ~ 回车, 对应 Procexp 线程列表占用 CPU 高的 TID 对应这边十六进制ID
然后 ~*e!mk 回车 列出所有线程堆栈, 然后, Bingo!
完整的堆栈信息弄到了, 足足61个堆栈帧, 详细的列出函数名称, 部分还提示了源代码行号.
这样就能够精确定位占用CPU高的功能代码块了! 乂目
Tips.
符号路径格式以及地址: srv*C:\SymbolCache*http://msdl.microsoft.com/download/symbols
加载sosex: >.load sosex
首次发布Aio1Ef - .NET程序打包压缩成单文件发布,支持非托管程序集[更新2]
作者:V君 发布于:2015-7-11 23:11 Saturday 分类:折腾手记
有样学样递归简称 Aio1ef In Only 1 Exe File,使用方法:
-
Aio1Ef.Packer <sourceDir> <mainAsm> <outputAsm>
- 指定目录和主程序, 打包整个目录
▲ 目前并不会排除多余的vshost.exe和xml文档,建议用好成事件 -
Aio1Ef.Packer <mainAsm> <outputAsm>
- 指定1个源文件和目标文件名, 仅打包1个文件 -
Aio1Ef.Packer <mainAsm>
- 指定1个源文件 打包到自动命名目标:文件名.Aio1Ef.扩展名
打包实现原理及流程:
- 基于指定的文件创建带有路径/大小的文件信息列表
- 按列表顺序固实压缩文件内容
- 用文件信息列表内容自动编写加载器配置代码
- 动态编译输出, 追加压缩数据到输出文件末尾
- 关闭输出文件, 结束.
运行时解包加载实现流程:
- 以只读方式打开自身, 按压缩后数据大小, 从末端seek回来并读取到内存
- 使用自身最后修改时间+主程序名+未解压的数据哈希值生成临时文件夹名称
- 如果文件夹已存在则直接使用, 否创建对应路径并解压到里面
- 设置启动环境(添加path环境变量,设置当前目录,SetDllDirectory) 加载调用主程序
需要注意的地方:
- 确保项目生成目标平台(x86、x64)与 Aio1ef 的匹配
- 必须对 WinForms 应用程序的初始化做辨别:
Application.SetCompatibleTextRenderingDefault(false);
这一句需要检测 NativeWindow 的 AnyHandleCreated 私有属性为 Flase 时才执行
否则重复调会用引发异常导致程序无法启动,参见这行源代码示例 - 由于是在临时文件夹加载(并非直接运行)主程序, 文件目录需要谨慎处理
相对路径(当前路径)是临时目录想在exe旁边操作文件
必须在路径前面加上应用域基础路径 - 对于DllImport有文件夹,例如 dlls/fmod.dll 这种方式将会找不到文件, 尚无解
- 不支持 .exe.config 配置文件
尚未实现:
将程序集Attributes添加到输出文件
■更新
将主程序图标应用至输出文件
生成输出文件将会带上主程序集特性:
AssemblyTitle,AssemblyDescription,AssemblyConfiguration,
AssemblyCompany,AssemblyProduct,AssemblyCopyright,
AssemblyTrademark,AssemblyCulture,ComVisible,Guid,
AssemblyVersion,AssemblyFileVersion,AssemblyInformationalVersion
■更新2
按检测到的应用程序类型(控制台/窗体)添加[System.STAThread]在入口点
解决弹出打开对话框卡死的问题, 目前并不会自动检测
对于有此特性的控制台应用程序还是不会自动添加
■算法配置
压缩算法 LZMA 直接使用SevenZipSharp.dll托管代码
哈希算法 MurMurHash3 [已失效]https://code.google.com/p/smhasher/wiki/MurmurHash3
blogger
Google Web Translator
热门日志
随机日志
最新日志
最新评论
- V君
@Quartz:(出现)... - Quartz
怎么不见人了呢... - V君
@Soar:DHCP 协议相... - V君
@Soar:当然是非... - Soar
@V君:谢谢 有空... - Soar
搞一个 1230v3+B85... - V君
@Soar:另外,也可... - V君
@Soar:iscsi服务端... - Soar
难怪这么卡,尤其... - Soar
clone了源码,提示...
分类
存档
- 2023年7月(1)
- 2023年5月(1)
- 2022年11月(1)
- 2022年10月(1)
- 2022年9月(1)
- 2022年8月(1)
- 2022年7月(1)
- 2022年6月(1)
- 2022年5月(2)
- 2022年4月(1)
- 2022年3月(1)
- 2022年2月(1)
- 2022年1月(1)
- 2021年12月(1)
- 2021年11月(1)
- 2021年10月(1)
- 2021年9月(1)
- 2021年8月(1)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(1)
- 2021年4月(1)
- 2021年3月(1)
- 2021年2月(1)
- 2021年1月(1)
- 2020年12月(1)
- 2020年11月(1)
- 2020年10月(2)
- 2020年9月(1)
- 2020年8月(1)
- 2020年7月(1)
- 2020年6月(1)
- 2020年5月(1)
- 2020年4月(2)
- 2020年3月(3)
- 2020年2月(1)
- 2020年1月(1)
- 2019年12月(1)
- 2019年11月(1)
- 2019年10月(1)
- 2019年9月(1)
- 2019年8月(2)
- 2019年7月(1)
- 2019年6月(1)
- 2019年5月(1)
- 2019年4月(1)
- 2019年3月(1)
- 2019年2月(1)
- 2019年1月(2)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(3)
- 2018年9月(4)
- 2018年8月(6)
- 2018年7月(4)
- 2018年6月(1)
- 2018年5月(2)
- 2018年4月(2)
- 2018年3月(3)
- 2018年2月(1)
- 2018年1月(1)
- 2017年12月(1)
- 2017年10月(2)
- 2017年9月(1)
- 2017年8月(2)
- 2017年7月(1)
- 2017年6月(5)
- 2017年5月(2)
- 2017年4月(2)
- 2017年3月(3)
- 2017年2月(2)
- 2017年1月(2)
- 2016年12月(3)
- 2016年11月(2)
- 2016年10月(3)
- 2016年9月(4)
- 2016年8月(2)
- 2016年7月(4)
- 2016年6月(3)
- 2016年5月(1)
- 2016年4月(4)
- 2016年3月(3)
- 2016年2月(1)
- 2016年1月(5)
- 2015年12月(4)
- 2015年11月(5)
- 2015年10月(1)
- 2015年9月(6)
- 2015年8月(4)
- 2015年7月(1)
- 2015年6月(6)
- 2015年5月(3)
- 2015年4月(3)
- 2015年3月(2)
- 2015年2月(1)
- 2015年1月(3)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年9月(3)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(3)
- 2014年4月(1)
- 2014年3月(1)
- 2014年2月(2)
- 2014年1月(1)
- 2013年12月(2)
- 2013年11月(2)
- 2013年10月(1)
- 2013年9月(3)
- 2013年8月(14)
- 2013年7月(7)
- 2013年4月(1)
- 2013年3月(4)
- 2013年2月(6)
- 2013年1月(6)
- 2012年12月(8)
- 2012年11月(6)