System.WebUI.SumtecReferencedException

从一个气压计想到的

posted on 2004-10-31 23:35:00 by sumtec  评论(22) 阅读(4625)

静下心来看看周围都发生了些什么……

posted on 2004-10-29 17:06:00 by sumtec  评论(16) 阅读(6612)

原来是 MarshalByRefObject 搞的鬼……

一个强制转换快还是ToString快，搞得我晕头转向的。以为OK了出结果了，却出现奇怪的情况，还好，总算是山穷水尽（复，李敖说的）疑无路，柳暗花明又一村。

一开始，我想大家都跟我猜想的一样，认为ToString比较慢，而且还有危险。结果一开始我的试验结果跟我的猜测比较吻合，ToString比强制转换要慢一个级别，不同的机子上面会有不同的结果，在10：1到6：1之间。但是后来有人说在Console下面不一样，问题就变得让我困惑起来了。事实上这个跟GDI，跟Form本身，跟DoEvents函数统统没有关系，因为我没有动用到无关的东西，也没有把非必要的部分给测量出来。更让我感到有趣的是，即使是在Console下面，只要自己写的类继承自Form，测试结果就会变慢。如果取消继承关系，两者的速度就会相差无几。认为Form的初始化会比较复杂，会动用Native资源，会在释放对象的时候有效率问题，这些都是错的，因为我很明显没有不断的进行构造和释放，也没有把这部分的时间计算在内。那么到底是什么问题呢？昨天没有时间进行试验，今天一大早起来就是为了进行测试。
其实我一开始就在汇编底下注意到那个ToString之后的调用，总觉得很奇怪：为什么不用强制转换之后的那一个赋值调用呢？（就是下面这个）
00000112  mov         esi,eax
00000114  push        esi 
00000115  mov         ecx,edi
00000117  mov         edx,995358h
0000011c  call        71E7021D

所以我从一开始就怀疑性能损失在这个地方，但是因为暂时没有办法调式到内部（MS的调试器……），所以我只能够进行一些猜想：是不是跟测试所在的实例有关系呢？
用一句代码来举一个例：
s = o.ToString();
本来觉得性能应该仅仅取决于调用了什么方法（ToString还是强制转换），以及所调用对象本身的类型（跟o有关）。比如考虑到ToString是虚函数，也许会有关系。但是后来看到这一系列奇怪的结果之后，不得不怀疑这个测试还跟this有关系。

首先我就猜测，是不是跟继承的深度有关系？如果是这个问题就太荒谬了，但是Form类和自己写的类之间的差别之一就是继承深度，还是有嫌疑的理由。为了验证这个问题，写了两个类：

public class TestBase
{
   protected const int testRound = 100000000;
   private string sTestBase;
   public void Test();
}

public class First : TestBase
{
   private string sFirst;
   public void FirstTest();
}

构造相应的实例并本别调用Test和FirstTest，函数内部的代码大致如下：

object o = "Hello! this is a test!";
long dt;
int i;

dt = DateTime.Now.Ticks;
for (i = 0; i < testRound; i++)
{
    sFirst = (string) o;
}
dt = DateTime.Now.Ticks - dt;
Console.WriteLine(dt.ToString("N"));

dt = DateTime.Now.Ticks;
for (i = 0; i < testRound; i++)
{
    sFirst = o.ToString();
}
dt = DateTime.Now.Ticks - dt;
Console.WriteLine(dt.ToString("N"));

这里写成两个函数主要是避免虚函数可能带来的影响，尽管不太可能，还是不要节外生枝比较好。测试的结果表明几乎没有任何差别，我还是不死心，把继承深度从1层扩大到3层，测试结果还是一样，因此排除了继承深度带来的影响。
然后我只好怀疑是否因为对象内部实现了某些接口造成性能上面的差异，因为Form内部确是有实现不少的接口，尽管也挺荒谬的。于是我又写了一个类：

public class Second : First, ICloneable, IComparable, IFormattable, IServiceProvider, IDisposable, IConvertible, ICustomFormatter, IAsyncResult, IAppDomainSetup, IDbCommand, IFeatureSupport, IFileReaderService, IContainerControl, IDataAdapter, IButtonControl, ICommandExecutor, IDbDataParameter, IColumnMapping, IMessageFilter, ITableMapping, IWin32Window, IWindowTarget, ITableMappingCollection
{
    private string sSecond;
    public void SecondTest();
    // 接口实现就不贴上来了
}

不要怪我狠心，我开始的时候添加了三个接口，观测到几十毫秒的差异，于是就一路添加上去。最后发现差别不会超过100毫秒，并且很可能是误差造成的。现在添加了二十多个接口都没有问题，那么到底问题在哪里呢？
再看就剩下Form的父类没有研究了，难道还真的是构造函数里面有些损耗性能的东西？那就太郁闷了，也非常荒谬。没办法，猜测不解决问题，还是来测试一下吧。看看怎么个测试法呢？想了想觉得还是从最上面的父类开始找问题，也就是说设计一个从MarshalByRefObject派生的类：

public class Fourth : MarshalByRefObject
{
    private string sFourth;
    public void FourthTest();
}

不测不知道，一测下一跳，问题就是由MarshalByRefObject引起的，试验结果跟前面的10：1非常吻合。后来为了挖掘更多的数据，我做了更多的相关测试，例如测试函数是实例上的，但是sFourth则是静态的结果会怎么样？如果函数是静态的，但是全局变量是实例上的呢？两者都是静态的呢？所以还写了更多的函数来测试：

public void TestStatic()；
static public void StaticTest(Fourth fourth)；
static public void StaticTestStatic(Fourth fourth)；

这个测试我在.NET 1.1(DEBUG)、.NET 2.0(DEBUG/RELEASE)下面分别测试，测试结果数据如下：

posted on 2004-10-29 13:48:00 by sumtec  评论(20) 阅读(7240)

一切都不能够想当然D

private class Tester
{
            private string testString;
            private const int testCount = 100000000;
            public void TestConsole()
            {
                  //  test it!
            }
}

posted on 2004-10-28 18:24:00 by sumtec  评论(16) 阅读(4996)

两种方式谁快谁慢——我的实践AND发现了与此无关的意外惊喜

        private string testString;
        private const int testRound = 100000000;
        private void button1_Click(object sender, System.EventArgs e)
        {
            object o = "Hello! this is a test!";
            int i;
            long dt;

            dt = DateTime.Now.Ticks;
            for (i = 0; i < testRound; i++)
            {
                testString = (string)o;
            }
            dt = DateTime.Now.Ticks - dt;
            textBox1.Text = dt.ToString("#,###,###,###");
            Application.DoEvents();

            dt = DateTime.Now.Ticks;
            for (i = 0; i < testRound; i++)
            {
                testString = o.ToString();
            }
            dt = DateTime.Now.Ticks - dt;
            textBox2.Text = dt.ToString("#,###,###,###");
            Application.DoEvents();
        }

这个实验我分别在VS2k3和VS2k5里面实验过，并且分别用Debug和Release两种模式去测试，测试结果如下：
DEBUG: （强制转换：ToString）
@2k3
11,406,250 : 123,125,000

@2k5
10,468,750 : 123,906,250

RELEASE:
@2k3
12,500,000 : 118,593,750

@2k5
7,031,250  : 13,906,250

大家首先会发现如下结论：
1、强制转换的速度在0.7秒到1.3秒之间，而ToString则基本上处于10秒以上的级别（有特例）。所以我极度怀疑Ninputer的测试结果是错误的，因为他的两个结果都是在0.6秒左右，当然还有一个特例跟Ninputer的数据相对接近，但是请继续看下面的结论。

2、这里有一个唯一的特例，就是VS2k5的Release模式，大家可以看到ToString的速度从10秒级别急剧减少为1秒级别，这个就是我题目所说的意外惊喜。但是即使是这样，ToString仍然比强制转换慢了50%，同时该数据还是P4HT 2.8GHz 1G Ram的机器上面测得，如果要ToString达到Ninputer所说的数据，我估计得要P4HT 4GHz以上的CPU，或者P4HT双CPU才有机会。还有，Ninputer的数据仅仅相差10%左右，这个跟我的实测数据完全不吻合。因此我估计Ninputer的测试很可能是因为代码不合理，被JIT短路了（优化了），如果将转换结果保存在全局变量里面，也许就不是这个结果了。
      关于为什么VS2k5的ToString在Release模式下面会有这么大的性能提升，我想还需要另外做实验去证明，现在还不好胡乱发言（虽然已经有自己的想法了）。

3、大家如果更加仔细的去看强制转换的数据，就会发现VS2k5无论在哪一种情况下面，都会比VS2k3的数据要快那么一点点，大约10%到30%不等。关于这个我可以马上给大家一个解释，这个实际上是.NET Framework 1.x和2.0之间的问题，但是这需要观察JIT之后的Native Asm，难度有点高。请看片断：

.NET Framework 1.1:
                testString = (string)o;
00000063  mov         edx,dword ptr [ebp-0Ch]
00000066  mov         ecx,79BF9AF8h
0000006b  call        71E608BC
00000070  lea         edx,[ebx+000000ECh]
00000076  call        7204C590

.NET Framework 2.0:
                testString = (string)o;
0000007c  test        ebx,ebx
0000007e  je          0000009A
00000080  cmp         dword ptr [ebx],788ED668h
00000086  jne         0000008C
00000088  mov         eax,ebx
0000008a  jmp         00000098
0000008c  mov         edx,ebx
0000008e  mov         ecx,788ED668h
00000093  call        75621D76
00000098  jmp         0000009C
0000009a  mov         eax,ebx
0000009c  mov         esi,dword ptr [ebp-40h]
0000009f  lea         edx,[esi+00000104h]
000000a5  call        7561BBB0

在这里大家可以清楚地看到，.NET Framework 1.1 仅仅是简单的将强制转换交给一个函数来处理（红色部分），但是2.0则首先进行了一些简单的处理，例如先判断是否是null（test ebx, ebx），以及判断o是否就是恰好string类型而不是string的子类型（cmp dword ptr [ebx], 788ED668h）。当然了，string是一个sealed的类型所以明显不可能有子类型，如果我要求强制转换成Form呢？如果这两项都失败了，才会和1.0里面一样调用一个函数来判断。所调用的函数实际上是将ebx所引用的对象里面的类型向上查找其父类型，看看有没有string类型（788ED668h），可以预见这是一个相对较为耗时的操作。而在我们实际的应用里面，如果进行强制转换通常都是直接转化成他的实际类型的，因此这一小段代码能够较为明显的提高系统的性能。不过这里也可以看到，优化过程还是做的不够，应该将86到8a这三句简化成一句je 0000009A。

我们再来看看ToString的情况。由于ToString是一个virtual的函数，被string类型override了，因此必然需要查v-table来进行正确调用。通过查看.NET Framework 1.1 所JIT出来的代码，可以清楚地看到这一点：

                testString = o.ToString();
00000108  mov         edi,ebx
0000010a  mov         ecx,dword ptr [ebp-0Ch]
0000010d  mov         eax,dword ptr [ecx]
0000010f  call        dword ptr [eax+28h]
00000112  mov         esi,eax
00000114  push        esi 
00000115  mov         ecx,edi
00000117  mov         edx,995358h
0000011c  call        71E7021D


这里ebx指向object o的类型描述，ebp - 0Ch指向object o对象本身（其实这里的负偏移12个字节就是类型描述，两者实际上是完全紧挨着的），其第一个dword就是string类型本身的数据（不是实例的数据）。我并不是非常清楚里面的一些实现，通过观察，估计可能里面包括了本类型的一些描述，父类型和接口的描述，里面偏移0x28应该就是vtable的实质内容（估计），其第一个就是指向ToString实际函数地址的指针。后面一个调用估计应该是一个赋值调用，和ToString调用可能没有太大的关系。为了证实我的想法，我甚至跟踪到第一个调用内部，发现确实是到了string.ToString()里面（大家可以看Disassembly页的Address下拉框，里面现实的是System.String.ToString），其代码如下：
00000000  push        esi 
00000001  mov         esi,ecx
00000003  mov         eax,esi
00000005  pop         esi 
00000006  ret 

分析到这里，我仍然不能够确定为什么ToString比强制转换性能相差10倍的原因。如果非要我估计一下，那么我会这么比较：
强制转换一共经历了：两个“比较+条件转移”，一个寄存器间赋值，一个索引器加偏移到寄存器赋值，一个普通调用（内部经历过程已经在前面分解了），一个赋值调用（内部无法分析）。
ToString一共经历了：5个寄存器间赋值，一个常数到寄存器赋值，两个间接（加偏移）地址到寄存器赋值，一个寄存器压栈，一个寄存器加偏移量间接地址调用（内部已经在前面分解了），以及一个赋值调用（内部无法分析）。

除去无法分析的部分，ToString比强制转换多出将近一倍的汇编指令，并且还包括比较耗时的间接地址赋值调用指令。光是这个差别，估计就应该有至少150%的性能损失。但是现在性能相差接近10倍，难道是仅仅因为那几句间接寻址的指令造成的？那就有点不可思议了。其实我有点怀疑ToString后面第二个调用内部有一些损失性能的指令（也许是多余的指令），如果我们看看.NET 2.0 Release版本的数据，也许是应该这么解释吧？有关这个问题需要做更多的研究……

嗯，今天的Post的正式内容到此结束。PS一下：
1、twodays在cnblogs里面的Post里面回复说：
“o.ToString() 实际上是调用了从object继承出来的ToString()虚函数，这一个虚函数在string类型里面被重写，代码如下：”

不对，因为你的o这会儿本来类型就是object，而不是string，所以他调用的实际上应该是object的ToString方法里面的内容，经过Reflector查看，里面的内容是：
return this.GetType().FullName;

这里我可以明确地告诉你，你错了（包括后面表示赞同的“小新0574”），至于为什么我会另外在一篇Post里面给出解释，因为这两个问题的难度级别相差太大了，在这里写也许很多朋友已经看得迷迷糊糊的了，继续看下去效果不好。

2、我记得有人在上一个Post里面问过as操作性能如何，我也做过试验了，性能没有差别，至少用肉眼观察数据结果是看不出来的。也许在Disassembly层会有细微差别，但是我没有兴趣再研究下去了。

3、有人说自己写的类里面ToString()可能会抛出Exception的问题，其实我是这么认为的。如果你在代码里面抛出Exception的话，那应该是一件相当遗憾的事情。因为ToString()没有任何参数，不可能因为参数问题引起异常。同时ToString函数的含义是，安全的返回关于该实例的信息，因此从感情上来说就不应该出现Exception的情况。很多时候我们就是利用ToString的一些特性来完成一些简单的事情，例如在ListBox里面加入一个不是String的对象，但显示的是用户能够理解的信息，这样用户方便选择，我们则方便编写代码。如果你的类会在ToString里面抛出异常，那么整个程序就会因此而不稳定。总之我认为在ToString() 里面抛出异常并不是这个函数存在的本意。

posted on 2004-10-28 14:32:00 by sumtec  评论(18) 阅读(4149)

两种方式谁快谁慢？

假设我有一个object类型的变量o，需要转化成string类型的变量s。那么请问下列方式当中的那一个方案更加有效率：

1、

s = (string) o;

s = o.ToString();

public override string ToString()
{
      return this;
}

posted on 2004-10-27 16:37:00 by sumtec  评论(12) 阅读(5579)

不明白为什么VS2k5编译for的时候……

今天在做一个实验，突然发现一个不寻常的地方：VS2k5 C# 在编译for循环的时候，IL代码跟以前的方式不一样：

      L_0029: ldloc.1
      L_002a: ldc.i4 100000000
      L_002f: clt
      L_0031: stloc.s flag1
      L_0033: ldloc.s flag1
      L_0035: brtrue.s L_0018

这个for循环的C#语句大致为
for (num1 = 0; num1 < 100000000; num1++)

上面IL里面所显示的正是比较num1是否小于100000000的片断，如果在VS2k3里面，则应该编译成：
      L_0029: ldloc.1
      L_002a: ldc.i4 100000000
      L_002f: blt.s L_0018

仔细再研究一下，发现这个变化只在Debug模式里面出现，也就是说这个变化并不是为了效率考虑的。但是原来的方式也能够比较容易的进行调试跟踪，实在搞不清楚为什么要用clt的方式。更加奇怪的是，在clt比较得出结果之后，还要弦弹出来保存到一个flag1的本地变量里面，然后再重新压栈。想了想，可能还是为了“更”方便的进行调适吧：比如说在IL级别进行调试的时候，可能看堆栈是不方便的，同时看两个变量的关系也是让人眼花的（n位数字比较，光是对齐数字就头痛了）。通过这样的IL变化，我们可以简单的看看flag1到底是什么结果。如果发现不对了，还可以在跳转之前把当前执行语句移到其他地方，或者修改转移条件，甚至不需要修改循环变量。这些在以前估计是不可能的，因为blt直接就判断并跳走了，就算可以修改转移条件，也必然影响循环变量i。如果考虑的更深入一点，我们可以简单的修改一条IL指令，使得flag恒为true或者false，强制控制流按照我们希望的方式去走，但是又不影响所有源代码里面的变量，这样子也许能够轻易的进行全覆盖的单元测试。不过这么强的能力目前好像还没有看到C#里面有相应的操作项，所以一切都只是猜测。真正的原因也许需要查找更多的资料，或者问问C#项目组的人员才知道了。

顺便说一下，最新版本的Reflector好像有点奇怪，在同一个函数里面IL结构完全一样的两个循环，前面一个会被翻译成while，后面一个会被翻译成for，也不知道是从什么时候开始的。因为这个是在看VS2k5 C#的Release模式编译出来的程序发现的，我一开始还以为这是VS2k5的优化成果呢……

posted on 2004-10-27 16:16:00 by sumtec  评论(7) 阅读(3304)

对GlobalHooks的进一步分析

This hook is called in the context of the thread that installed it. The call is made by sending a message to the thread that installed the hook. Therefore, the thread that installed the hook must have a message loop.

原来是发送消息给设置全局钩子的进程，怪不得对.NET的程序特别亲切了。不过在JournalRecordProc和JournalPlaybackProc里面都没有说到是通过消息来传递的，更没有像上面提到的那样，需要有一个message loop。不过事实上我想无论如何这两个钩子都需要有消息循环，原因很简单，系统在用户按下：Ctrl-Break/Ctrl-Alt-Del/Ctrl-ESC三者当中任意一个的时候，就会给应用程序发送一个WM_CANCELJOURNAL的消息，也许因为这样默认客户程序必须有一个消息循环吧……（还是不敢确定）
但是问题又来了，为什么其他的钩子就不能够用同样的方法呢？基于安全或者性能的考虑？这个我暂时就不太清楚了。此外，我开始还以为WH_SYSMSGFILTER也是可以在.NET里面设置的，但是详细一看发现原来不是，看来.NET里面能够使用的全局钩子也就这四个了。

posted on 2004-10-26 15:14:00 by sumtec  评论(13) 阅读(3809)

C#本地变量声明趣味解析

我们先来看看展波举的例子：
http://blog.joycode.com/zhanbos/archive/2004/10/26/36605.aspx
在这个例子里面我们看到，编译器会检查scope问题，目的是防止错误使用本地变量。但是据我研究，这里面有“Bug”（注意双引号），那么会有什么有趣的“Bug”呢？我来给大家一个简单的例子：

        public void Test()
        {
            {
                int a;
            }
            {
                int a;
            }
        }

在这个Test函数里面有两对大括号，标明两个互不相属的子范围。这里大家也许看的非常不习惯，因为没有人光秃秃的写这么两对大括号的。我跟大家说：没关系，编译器承认光秃秃的大括号的，这个也是标准C里面的规范之一，作用就是把大括号里面的所有东西认为是“一句话”，准确点讲是逻辑语句，同时内部是一个范围，约束范围内的本地变量不会往外传播。如果大家实在看不习惯了，可以自行加上诸如while(true)之类的前缀，就习惯了。
那么这段代码有什么Bug呢？没有，确实没有Bug，编译顺利通过。当然，显示了两个Warning，说a没有被用到，无伤大雅。我们首先来分析一下，编译器怎么给把这个给弄通过的呢？我们用Reflector来看一下（当然，因为没有切实的代码，所以只能够看IL，而不能够看C#）：

.method public hidebysig instance void Test() cil managed
{
      // Code Size: 2 byte(s)
      .maxstack 0
      .locals (
            int32 num1,
            int32 num2)
      L_0000: nop 
      L_0001: ret 
}

 

哦！原来编译器把内部的变量改名字了！或者说编译器把他们当作完全不同的两个变量来对待。同时我们在这里也可以看出来，实际上在IL里面时不区分范围的，只有本地变量着一个简单的概念。无论你在哪个范围，在什么时候开始声明，实际上都是在函数的一开始用一个.locals这样的伪语句来声明的。这么做是简单省事的办法，因为如果在用户源代码实际声明的地方才在栈上面开辟空间，那么最后函数退出的时候就不知道该释放多少栈空间了。当然这不是不可以解决的，但是那样的话增加了不必要的复杂度。如果我来设计.NET Framework，我也会通过高级语言的编译器来约束范围问题，而不是摆到IL里面去解决。（毕竟IL里面没有这样的功能不影响我们写程序）稍微引申一下，我们就知道，一个函数里面有多少个本地变量，取决于整个函数内部声明了多少本地变量，而与变量所在范围无关。在IL这一层里面暂时我们没有看到这样的优化工作，我们可以看看这样的代码最后被编译器编译成什么了（用Release模式编译）：

        public int Test()
        {
            int b;
            b = new Random().Next(5);
            if (b < 5)
            {
                int a = new Random().Next(5);
                Console.WriteLine(a);
                b = a;
            }
            else
            {
                int a = new Random().Next(10);
                Console.WriteLine(a);
                b = a;
            }
            return b;
        }

Reflector 反编译结果：

public int Test()
{
      int num1 = new Random().Next(5);
      if (num1 < 5)
      {
            int num2 = new Random().Next(5);
            Console.WriteLine(num2);
            return num2;
      }
      int num3 = new Random().Next(10);
      Console.WriteLine(num3);
      return num3;
}

大家可以看到num1是b，num2和num3则是分别的两个a。事实上这两个a互相之间是没有任何冲突的，也就是说是完全可以重用的，编译原理里面也有一个变量重用的优化，但是这里看不到有这样的优化，我觉得比较吃惊。虽然说这也可以算是一种Bug（严格说来是也不是），但是我要说的“Bug”不是这个。

分析完上面这些基本知识，我就来劲了：

        public void Test()
        {
            {
                int a;
            }
            {
                int a;
            }
            int a;
        }

看，编译出来之后却出现了错误：
error CS0136: A local variable named 'a' cannot be declared in this scope because it would give a different meaning to 'a', which is already used in a 'child' scope to denote something else
哦，原来这个跟声明的顺序还没有关系，只要子范围里面有a了，那就不能够再定义这个变量了。这个难道跟IL里面所有变量都在函数开始部分声明有关系？看起来好像是这么一回事，但是实际上不是，因为C#的编译器完全可以像前面那样，把最后一个a当作另外一个变量。这到底是怎么回事呢？我们需要作本次探索的最后一个实验：

        public void Test()
        {
            a = 2;
            {
                int a;
            }
            {
                int a;
            }
            int a;
        }

这下可好，除了刚才那个错误之外，还多出来另外一个：
error CS0103: The name 'a' does not exist in the class or namespace 'ConsoleApplication1.Class2'
也就是说，编译器根本就没有把后面那个a当作从函数一开始的地方定义来看待。但是这两个错误合起来反而容易让我们产生这样的错觉和悖论：
因为前面两个a在范围外面就应该消失其影响力，那就不应该跟后面的a产生冲突。但现在既然你说了，第三个a的定义根前面那两个a的其中某一个定义相冲突了，那我就只能够认为后面这个a实际上在前两个a被定义出来之前就已经存在了，因为后面这个a处于外层范围，它不会在内层范围失去作用之前失效，这样还能够解释得通。可是这么解释我只能够认为外层的a应该在函数一开始的地方就生效了（老式的C编译器有一段时间确实是这样的），可是偏偏还来一个CS0103错误！解释不通，有“Bug”！

最后我来修正这个我一开始提出的说法，其实并没有Bug。得出有Bug的结论，那是从纯粹的语法角度看这个问题的，我也觉得应该容许在第三个a的定义出现，顶多只给出一个Warning。但是微软却给出了一个错误，我想这是从避免不必要的Bug的角度考虑，尽量保护开发人员避免不必要的烦恼。开发人员确实很有可能在定义了第三个a的时候忘记第一二个a已经失效了，同时也忘记了自己定义过第三个a，还以为自己用的是第一个或者第二个a里面的数据。不过对于这种解释，我还是有意见的：既然约束已经缩窄到这个地步了，那为什么要允许第二个a的定义呢？如果开发人员会忘记自己定义过第三个a，有什么理由认为不会把第二个a的定义给忘记了，以为自己在用第一个a呢？

本来上面所写的那些统统都是垃圾代码，我认为，在一个函数内部根本就不应该有相同的变量来迷惑自己。C#的编译器在这些问题方面确实有相当严谨的考虑，不过我还是觉得有一些“悖论”存在，如果能够更加严谨，我认为只会更好。

posted on 2004-10-26 13:13:00 by sumtec  评论(4) 阅读(2466)

给各方的一个预警信息

 今天我才知道我在博客堂的Blog被人污染了，有人在回复里面贴这种东西：

为了避免有人认为我是在这里对其宣传（这个罪名可是担当不起），因此这里截断了，只是为了显示证据。这样的回复一共有四个，每一个的用户名是一样的，但是里面的连接却都不一样，我已经全部删除了。不知道这个现象以前有没有发上过，反正我是没有遭遇过，一直以为只有那些很垃圾的论坛才会被这种东西骚扰，看来这种骚扰哪里都会存在。其他的诸位博客看来得小心你自己的blog里面也留有这样的回复而不自知，所以经常管理自己的blog还是必需的，至少从这个角度讲是必需的。

另外开心和dudu是否都要看看这个问题是否需要注意了，至少我觉得会有很多人不愿意看到自己的blog里面有这样的留言。如果说现在是小规模个别事件还好说，如果出现大规模同类事件是否会引起大量的投诉，甚至某些部门也出面了，那就比较麻烦了，还是提前准备比较好。其实出现这种现象也许也算是一件好事，说明网站出名了。但是马上我又想到另外一件事情了，你说会不会有DOS攻击之类的事情呢？这个就扯得比较远了。

其实我也担心是否有人给我结仇了，故意这么损我的……如果是这样我首先要反省，说话还是需要更加客气。不过贴这种东西的人是不是需要小心一点，惹毛了一堆developer（多数是精英）也不是什么好玩的事情。（想想对方还不一定认识字呢……）

posted on 2004-10-26 11:44:00 by sumtec  评论(11) 阅读(1630)

（IV）.NET CF二进制文件操作+ SmartPhone开发思考

posted on 2004-10-23 04:59:00 by sumtec  评论(11) 阅读(2814)

今天晚上发飚了，来一段“浮动”窗口的代码

        private const int WM_NCHITTEST = 0x0084;
        private readonly IntPtr HT_CAPTION = new IntPtr(2);
        protected override void WndProc(ref Message m)
        {
            if (m.Msg == WM_NCHITTEST)
            {
                m.Result = HT_CAPTION;
            }
            else
            {
                base.WndProc(ref m);
            }
        }

posted on 2004-10-23 03:14:00 by sumtec  评论(11) 阅读(6424)

（III）继续探讨.NET CF下大规模数据读取和保存

public override long get_Position()
{
      if (this._handle == HostNative.INVALID_HANDLE_VALUE)
      {
            __Error.FileNotOpen();
      }
      if (!this.CanSeek)
      {
            __Error.SeekNotSupported();
      }
      this.VerifyOSHandlePosition();
      return (this._pos + ((this._readPos - this._readLen) + this._writePos));
}

private void VerifyOSHandlePosition()
{
      if (this.CanSeek)
      {
            long num1 = this._pos;
            long num2 = this.SeekCore((long) 0, SeekOrigin.Current);
            if (num2 != num1)
            {
                  this._readPos = 0;
                  this._readLen = 0;
            }
      }
}

private long SeekCore(long offset, SeekOrigin origin)
{
      int num1;
      int num2 = PAL.File_Seek(this._handle, (int) offset, (int) origin, out num1);
      if (num2 != 0)
      {
            __Error.WinIOError(num2);
      }
      this._pos = num1;
      return (long) num1;
}

posted on 2004-10-23 01:24:00 by sumtec  评论(3) 阅读(1601)

继续：.NET CF下面“大”规模数据的读取和保存

<Root>
  <Item id = "1" name = "hello" something = "xxx" extension = "yyy" abc = "efg">Text</Item>
  <Item id = "2" name = "world" something = "zzz" type = "reference" extension = "123">China</Item>
  ……
</Root>

        void Test()
        {
            // Create an 1MB file for testing, make the buffer size of filestream object to 640k
            FileStream fs = new FileStream(
                "Test.Binary",
                FileMode.Create,
                FileAccess.ReadWrite,
                FileShare.None,
                655360
                );
            byte[] buff = new byte[1048576];
            fs.Write(buff, 0, buff.Length);

            long ticks;

            // Reset the position
            fs.Position = 0;
            BinaryReader br = new BinaryReader(fs);
            // Test reading every byte from BinaryReader using for statement:
            ticks = DateTime.Now.Ticks;
            for(i = 0; i < buff.Length; i++)
            {
                br.ReadByte();
            }
            ticks = DateTime.Now.Ticks - ticks;
            MessageBox.Show(ticks.ToString());

            // Reset the position and test reading every byte using while statement:
            fs.Position = 0;
            ticks = DateTime.Now.Ticks;
            while (fs.Position != fs.Length)
            {
                br.ReadByte();
            }
            ticks = DateTime.Now.Ticks - ticks;
            MessageBox.Show(ticks.ToString());

            // Reset the position and test reading via MemoryStream
            // using while statement:
            fs.Position = 0;
            ticks = DateTime.Now.Ticks;
            // we define another buffer to test mem alloc time all together
            byte[] buffRead = new byte[buff.Length];
            fs.Read(buffRead, 0, buffRead.Length);
            MemoryStream ms = new MemoryStream(buffRead);
            br = new BinaryReader(ms);
            while (ms.Position != ms.Length)
            {
                br.ReadByte();
            }
            ticks = DateTime.Now.Ticks - ticks;
            MessageBox.Show(ticks.ToString());
            

            fs.Close();
            
        }

posted on 2004-10-23 00:38:00 by sumtec  评论(0) 阅读(2115)

在.NET CF下保存和读取XML文件数据不是一般的慢……

<Root>
  <Item attr = "something">
     <ID>1</ID>
     <Name>abcdef</Name>
     <Something ref = "alpha" type = "beta">abcdefg</Something>
     <Other type = "abc">1</Other>
     <Extension type = "linkSame">Parent</Extension>
     <Parent xxx = "yyy">3</Parent>
  </Item>
  
</Root>

的XML文件用XmlDocument直接进行读取，我的实测结果是：

当Item数量为150个左右的时候，读取所有信息需要时间大约为6-9秒。当数量为300左右时（此时文件大小大约为110k），时间大约需要11-14秒。当数量暴增到接近6000的时候（大小约为2M），时间需要大约200秒。在桌面下，我们可以轻松的使用XML来进行非结果化数据的存储，但是到了CE平台下面，我们就不能够继续这么干了，至少大量数据这么做是不行的。当然，XML也从来不是为了存储和检索大量数据而设计的，大家主要还是利用XML相对来说非常强大和灵活的描述能力来对一些非结构化的信息进行描述。虽然说6000项数据相对于大型数据库动辄上百万的级别来说还是芝麻绿豆，并且在桌面上也完全能够胜任（大概1.1秒），但对于SmartPhone这种资源较为有限的机器来说就是一个大规模级别的物体了。而非常不幸的是，.NET CF 1.0在这方面的设计也比较糟糕（据传说在2.0会有较大的改进），这两个条件的共同作用造就了上面那个非常糟糕的测试结果。这仅仅是把数据读进内存当中，还没有进行任何的处理，如果让用户去等待这么长的时间去读数据，估计用户肯定得把手机扔掉。

不过这不代表着没有任何改善的余地，比如说，我们可以把文件内容分割。前提条件是实际上不需要所有的内容，并且内容能够有效地分割（包括容易管理）。这个方法的好处是，仍然可以用XML来进行存储。有好处当然也有坏处：需要将内容分割，意味着你需要管理这些分割的部分，比如在程序需要的时候必须能够调度到内存当中，同时检索的难度也加大了（可能需要一个额外的索引文件或者机制来完成）。

在进行这样的分割之前，最好考虑一下是否有其他的解决方案，比如说XmlReader。说起来好像有点复杂，似乎要自己手动处理Xml文件，其实并没有那么复杂，比如下面的这个函数可以用来定位某一个指定的element：

        // Seek a specified element node.
        // true: The specified element was found.
        // false: reached the end of file
        bool SeekElement(XmlReader reader, string name)
        {
            while(reader.Read())
            {
                if (reader.NodeType == XmlNodeType.Element && reader.Name == name)
                {
                    return true;
                }
            }
            return false;
        }

当然了，相对于一句doc.Load(path)来说，还是会复杂不少。此外xml文件内容的结果复杂度也需要简化，这样才便于手动处理。好在我们也不指望在手机上做什么特别复杂的应用，比如说什么内容排版之类的，一般来说数据也不是很复杂。如果你同意我的说法，那么也许可以参考一下我写的代码：

        void Travel(XmlReader reader)
        {

            while (SeekElement(reader, "Item"))
            {
                if (reader.IsEmptyElement == false)
                {
                    FillAttributes(reader);
                    while (SeekElementWithEndCheck(reader, "Item") )
                    {
                        FillAttribute(reader);
                        if (reader.IsEmptyElement == false)
                        {
                            if (SeekTextWithEndCheck(reader, property))
                            {
                                text = reader.Value;
                                MoveToEnd(property);
                            } // end if Text found
                        } // end if Item is not empty
                    } // end while find elements under "Item" element
                } // end if element "Item" is empty
            } // end while seeking all "Item" elements
        }

        // Seek a specified element node.
        // true: The specified element was found.
        // false: reached the end of file
        bool SeekElement(XmlReader reader, string name)
        {
            while(reader.Read())
            {
                if (reader.NodeType == XmlNodeType.Element && reader.Name == name)
                {
                    return true;
                }
            }
            return false;
        }

        // Seek an element with checking the end of a specified element node
        // true: an element found(the name of element can be retrieve from reader.Name, etc.)
        // false: reached the end of file, or reached the *end element* node ""
        bool SeekElementWithEndCheck(XmlReader reader, string name)
        {
            while(reader.Read())
            {
                switch(reader.NodeType)
                {
                    case XmlNodeType.EndElement:
                        if (reader.Name == name)
                        {
                            return false;
                        }
                        break;
                    case XmlNodeType.Element:
                        return true;
                }
            }
            return false;
        }

        // Seek text within the bound of element *name*
        // true: text found (in reader.Value)
        // false: reached the end of file, or reached the  node.
        bool SeekTextWithEndCheck(XmlReader reader, string name)
        {
            while(reader.Read())
            {
                switch(reader.NodeType)
                {
                    case XmlNodeType.EndElement:
                        if (reader.Name == name)
                        {
                            return false;
                        }
                        break;
                    case XmlNodeType.Text:
                        return true;
                }
            }
            return false;
        }

        // travel all the attributes
        void FillAttribute(XmlReader reader)
        {
            if (reader.MoveToFirstAttribute())
            {
                do
                {
                    // fill your code here
                    Console.WriteLine(reader.Name + " : \t" + reader.Value);
                }while(reader.MoveToNextAttribute());
            }
        }

待续……

posted on 2004-10-22 23:10:00 by sumtec  评论(7) 阅读(2596)