winform时代,在vs的designer里拖啊拖啊,总是可以自动生成一个designer.cs,够(xiang)叼(si)的话你还能自己去改designer里的代码,运气好了vs的designer还能正常的识别,然后再继续拖拖拖。
unity3d的designer没有生成.cs,简直是,耍!流!氓!
先猜个原因再来做点实验:
前方高能预警(纯YY向)
原因:其实为的就是一点——performance,看不到unity源代码,但是从各种资料来看,unity是build with mono,而不是build on mono,链一张mono官方的图说明此关系:
So what?designer生成的根本就不是mono的managed code而是native code(或者是unity自己做的某种中间语言),如果能看到unity的源代码,托管部分的代码一定全都是[DllImport]
才对。没有对应的托管代码生成,哪儿来的designer.cs?
一拍脑袋,啥都想通了,render的部分尽量少搀和托管的代码,从而让整体效率更高。再转念一想,好像又不是这么回事,不管布局和动画参数之类的怎么调整,render的核心部分本来也不是运行在托管的环境下的。那只能理解为unity这样设计的原因让程序员犯错(乱搞)的几率变小,且效率更高。
不过,且不论unity设计的初衷(我会告诉你我越想越觉得前面的结论是瞎扯?),核心算法放在native空间里肯定要比managed空间里快,这点是毫无疑问的。
开始写代码,折腾起(总计折腾了一整个下午,才helloworld出来):
想要在windows下build一个嵌入mono(Mono JIT compiler version 3.3.0 不确定后续版本还有没改变)运行时的helloworld,步骤如下:
- 安装Mono的运行时
- Path什么的,我忘了是自己加的还是安装程序干的了。反正要确认在CMD下可以mono
- 用VisualStudio的自带的lib工具做一个.lib出来后续编译用:
lib /nologo /def:mono.def /out:mono.lib /machine:x86
- mono.def内容在此,官方的tutorial写的是错(至少在windows上)的
- c/c++已经玩不来了,研究了半天把include(mono安装后的include目录)和link(上面生成的那个.lib)搞定了
- 终于可以愉快的写代码了
代码旨在测试同一个算法在托管环境和非托管环境下实现的差距(代码没有经过仔细推敲,可能没啥说服力):
cpp:
csharp:
运行结果如下:
True
65535
65535
NativeFoo for 1000 times Time Elapsed 1681.5873 ms
ManagedFoo for 1000 times Time Elapsed 15382.2008 ms
10倍差距!虽然ManagedFoo肯定还有些优化的空间,还是足以验证我前面的YY还是有点道理的。
后面又写了个完全犯规的函数:
结果ManagedFoo2 for 1000 times Time Elapsed 2614.927 ms
,还是比不了啊(废话)。