V君的博客

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的哟)

标签: 软件开发 C# JIT

评论(0) 引用(0) 浏览(1580)

使用TcpView和ProcMon高效地诊断应用程序故障

作者：V君 发布于：2015-8-17 13:28 Monday 分类：填坑经验

收到通知说咱们的软件在客户的电脑上不工作, 于是通过远程协助到客户的电脑上做诊断.

咱们的软件分为一个 Winform 配置界面和一个 Windows 服务.

 

情况是这样:

通过配置界面输入参数, 然后启动服务开始工作. 

然而似乎配置不生效 -- 使用TcpView看到服务连接目标是默认值而不是配置文件指定的

另外日志文件也一点都不产生.

 

诊断及修正:

打开ProcMon, 把服务进程名添加到筛选器, 开始观察.

找配置文件以及日志的路径监视结果, 发现拒绝访问.

嗯 马丹 去配置文件目录一看, 只有Administrator...  

修正权限让服务进程能访问文件. 

重新启动服务, 这下问题解决 -- 服务进程已经按照配置的参数连接到目标

日志文件也出来了.  乂目

 

总结:

我大 Sysinternals 棒棒哒!

(文中的两个软件都是这群人整出来的)

 

吐槽: 企鹅远程太难用了...

标签: 软件开发 调试技术 软件故障诊断 Sysinternals

评论(0) 引用(0) 浏览(2525)

巧用自定义协议之跨浏览器实现网页调用本地票据打印机

作者：V君 发布于：2015-8-11 0:25 Tuesday 分类：挖坑经验

TL;DR: 

1) 注册自定义协议

C#实现

2) 实现处理程序

系统会把整个URL当成参数传递到你的程序, 切掉协议头(xxxx://)就可以吃了

用参数调用票据打印机

3) 从网页调用这个协议

推荐使用js设置隐藏iframe的src指向协议连接

 

听我扯扯:

阅读全文>>

标签: 软件开发 C# 自定义URL协议 票据打印

评论(0) 引用(0) 浏览(3680)

使用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

Windbg下载方法 sosex下载地址

标签: 软件开发 C# 调试技术 windbg

评论(0) 引用(0) 浏览(4754)