SUMTEC -- There's a thing in my bloglet.

@楼主:
Attach有另外一个重载：Attach(object, bool)
其中bool参数指出是新的还是旧的
另外好像其它子对象不需要Attach，前提是这些子对象的属性上有合适的标记，不太记得了，不对请批评。

@楼上:
冤枉啊！我不是速马……

@U2U:
这个确实叫作字符匹配，不过当时任务紧，一时间也没有转过弯来。你可以看看后面的算法，这个算法其实不咋样。

@Angel Lucifer:
顺便问问看，你看过.NET的HashTable吗？我粗看了一下，好象是用了桶方法，没有仔细看，所以不确定。你确定吗？

补充一个：
本人观点与楼主的观点并无太大冲突，只是在局部意见上有点差异或者误解。上面的长篇只是表达自己个人观点而已，并非说明楼主观点不正确，甚至剧烈冲突。请勿错误理解。

@朝晖的.net:
我也不太记得了，估计你得到Google上搜索一下，Site:csdn.net 哈希表 sumtec

@Angel Lucifer:
Cichelli方法是对字符串进行散列的一种函数，当然也可以推广到对不定长二进制值的计算。这个函数如下：
H(key) = h(first) + h(last) + h(length)
实际上，该方法也并不是所谓的完美函数。第一，该函数在面对woman、women，jan、jun的时候，确实是有冲突的；第二，该方法在大量数据时是很慢的。我想你大概也承认了这一点了。
至于FHCD算法，理论上应该是可以寻找完美散列函数的，不过这种完美函数不能简单的说是“无冲突散列函数”。或者说，这种函数的任务并不是为了制造出一个不会产生冲突的哈希表类。原因还是在于前面说的，永远不可能用有限集表示无限集。又或者说，如果插入一个新的值，就有可能破坏原有的完美函数，需要寻找一个新的完美函数。至少我认为，完美函数仍然是有冲突的，只不过解决冲突的办法变成了换一个新的完美函数。
当然，我并非说完美函数就没用了。完美函数显然比高冲突函数更有用，但这种解决方案也是有特定的优势和劣势的。其优势在于，如果存入哈希表的数据不经常变化，则可以通过该方法减少冲突。其劣势在于，如果插入哈希表次数和访问哈希表的次数接近时，有可能会因为寻找完美函数产生过高的时间消耗。

最后说时间复杂度O(n)，这个东西通常讨论的是最高次幂，并且也不讨论系数。但是，有的情况下，我也会讨论系数问题，尤其是系数高于n的情况下。例如数组和哈希表的比较。您说的“如果按照仁兄的方法，那么通过索引进行数组访问也不应该算作O(1)。因为这期间也有好多步骤要做”，我觉得反而有点极端了。
首先我们要确定O(n)得出的结果是什么？比如说O(n)=n，这个n是表示n个机器指令吗？显然不是。O(n)=n，通常是以某种较为费时的操作作为观测目标以及衡量单位的。例如说：比较，跳转，除法，幂运算等。当然，我们通常更笼统的是以某种特定的运算为单位。例如比较数组和哈希表，我们说O(n)=1，不是表示只要一个机器指令，而是说，我们通常认为数组就是最快的了，所以一个数组操作就是一个基本单位，这样我们才好继续讨论哈希表的时间复杂度。事实上，一个数组操作通常也确实是一个机器指令就可以完成的（连续操作的情况下）。比如说，对一个数组循环赋值i，我们可以得到类似如下的机器指令：
mov dx, 1234h
xor cx,cx
xor si,si
loop_start:
mov [dx+si], cx
inc si
inc cx
cmp cx, 100
jne loop_start:

其中mov [dx+si], cx，就是对数组某一个元素的赋值。那么在这样一个基础上，我们确实可以看出来，哈希表的O(n)=C，并且这个C还不是一般的小。如果用数组只要1秒就可以完成的工作，用哈希表也许就需要花10-100秒。这点差别在某些情况下不敏感，某些情况下却是敏感的，就要看具体的情况如何了。

在CSDN上讨论的时候，有的人就是非常敏感，非要说数组比哈希表快。我也承认确实是快，就因为哈希表的O(n)=C，而数组是O(n)=1。但是，对方却不愿意承认数组有可能无法完成哈希表可以完成的某些类型的问题，尤其回避了空间复杂度上的问题。准确说，哈希表是在技术所有数据结构和算法中，对空间复杂度和时间复杂度平衡得最好的其中一个。

至于范跑跑，我想到另外两个人 -- 神雕里的杨龙 -- 师道尊严被他们搞成那个样子，可恨！可恨！

神雕之类的书我没看过，只看过港片——问：杨龙是谁？两个人？杨过和小龙女吧？嗯，这文字说的真是太简炼了。

差不多，基本正确。

时间复杂度计算错误！
该排序的时间复杂度是：
Os(n) = D*Od(n)
其中n代表数据的数量，Od(n)则是对n个元素的某一特定单位（例如一个十进制位）的排序时间复杂度，D表示按照特定单位分割后，该标准元素可分割出来的数量。例如楼主中的例子，D=3，至于Od(n)是多少，就不知道，估计最快也就只能是接近O(n)。

因此，除非讨论的是超大数排序，并且一次对超大数的排序速度，比D次对某一小单位数排序的速度还要慢，这种排序才有价值。例如某种机器对64位数进行任何计算所消耗的时间，都是对32位数计算所消耗时间的4倍，那么这种排序才有可能有价值。

有意思，好文章！

网上有报告称SqlServer2000对多CPU的支持有问题，即使打补丁到sp4也还是不够的，需要继续打补丁到KBxxxx。具体多少我忘了，你可以查一下你的EventLog，应该会有这个相关的SqlServer异常的。（估计你已经升级数据库了，没机会了）

顺便说一下：
1做web，2做数据库的方法可能是错误的。因为就我所知，数据库服务器除了对硬盘性能敏感外，还对内存数量敏感。
此外，既然你有多台数据库，同时原来就支持Web和数据库分开的方式，那么把数据库和Web都放在3，也不是特别好的方法。因为两者肯定会有竞争，例如对磁盘读写的竞争，或者还有IIS Log和DB备份的磁盘剩余空间竞争。分开问题少一点，而且有的时候问题比较好判断——看那一台服务器资源状况出问题了就知道了，例如CPU高的是哪一台。

@Lucifer:
"理论上，存在一个完全散列函数。它从不会让数据发生碰撞冲突。"
这句话是错误的！任何散列函数都回产生冲突，不存在不冲突的散列函数。如果一个有限集能表示超过该有限集容量的超集的所有元素，那么无论这样的散列函数找起来有多难，人们都会花心思去找。更不要说用有限集去表示无限集的时候了，字符串就是一个无限集。比如假设有限集0-2^32-1，可以表示任意长度的任意字符的所有组合，比方1代表且仅代表A，2代表且仅代表B，如果真能这样，我们就不需要zip、rar了，直接用散列就能压缩了。
正确的说法是，理论上存在一个散列函数，对被计算数据的全集I进行计算，可以产生均匀冲突。即，每一个散列值，所代表的数据量都是一致的。好的散列函数是奔着这个目标去的，如果所有字符串算出来都是数值0，肯定不是一个好的散列算法，都影射到0、1、2也不是一个好算法。
事实上，那只是理论上的问题，实际的应用中，理论上好的算法，在特定场景中可能会失效。例如对英文单词做散列，用一个对不定长二进制值能够进行良好散列的公式，可能会导致对英文单词的散列计算产生不均匀结果。所以还是要讨论特定场景下，才能得出该算法是否接近理论的结果。当然，一般应用，这都不是很重要的问题。

另外，哈希表查值的时间复杂度，更准确应该说是O(n)=C (C>1)，而不是O(n)=1。因为哈希表不可能比数组快，每次查值要进行至少一次散列运算，一次模运算，一次比较运算，这已经是无冲突下的最简模式了。有冲突处理的情况下会更大。当然，数据量足够大，冲突足够小的情况下，和对折查找的Log级别比起来，可以认为是近似1。

@包建强：
不考虑空间影响，你的题目的答案就是开一个超大数组，直接应对你的表示空间，例如无符号整型值（4字节），那就开个4G的数组，几乎无敌手（前提是你有那么多内存，也确实不需要考虑空间大小的影响）。但这也是有前提条件的，如果这个100万个数中的任意一个的表示范围是不定长的，例如可以从负无穷到正无穷的任意数字，那么比较实际的还是用哈希表。当然了，如果硬要在这个时候说，那空间别考虑，无穷的空间也能给你提供，还不会影响速度，那照样是用无穷大的数组来最快。这个问题N多年前我在CSDN上和人争过，题目就是没有限制数据表示范围，我的答案就是哈希表。

@A1:
匿名的同志，难得有一个能在这种级别进行交流的人啊……
WM算法，我本身并没有贬低他的意思。算法在我看来也不就是一种武器，多数的时候我们只是在弓箭还是刀枪里面选择一个相对合适的，顶多也就自己给打磨得更加蹭亮一些。为什么我们选这个不选那个，为什么这么打磨不那么打磨，其理由应该是我们的任务目标。我在这里只是指出WM算法对于关键字过滤，并不显得有优势。我看到的有限的几篇需要使用用多模匹配的论文，都提到和DNA序列检测有关（或者类似的任务）。在这样的任务里面，其关键字都是非常长的，最短序列会比较长，至少都超过2-3个单位长度。在这样的任务里面，WM这种依靠“跳跃技术”提升性能的思路自然是非常合适的，甚至是再合适不过的。综上所述，俺似乎还是没有白活。

其实我确实担心有人会说，你可以看看XX算法。但是实际上任务都不相同，所以提前先把TTMP和WM的任务差异，以及由此导致的思路差异和性能差异都一一列举出来了。

我也是不是整天都有时间去搞这种类型的东西，现在年关了，产品升级完之后应急压力减轻，正好手头也有这样的任务，于是就发点狠仔细研究一把。目前这个研究算是差不多了，再往下还有很多东西挖，可是我也没有时间细挖了。我能够仔细的把这次的成果总结出来，就阿弥陀佛了。

其实之前写股票，也只是兴趣所致。关键是每天都对着代码，人会变得很无趣，再到博客上写长篇大论的，会反胃的。这么长时间没有写技术的东西了，写写也是比较有趣的，也比较有成就感，毕竟这也是一个创造发明（可惜专利法不承认“算法”！不然我就申请专利了）。

我可没有说过“从此金盆洗手”之类的话，造谣了啊！俺未来写什么的可能性都有。

@其他人：
本系列确实有点难度，一般来说知识和需要实现具体算法的人看。其他人嘛，其实我是建议看看类似的东西。使用人家造好的工具，对大脑来说只不过是一个适应的过程。如果是创造一个新的东西，才是大脑在做健身运动。

@楼主：
那我绝对建议你对ToLower做一个优化。这么说吧，同样是对一个大约280K个字符的文本进行检索：
原来没有执行ToLower的时候，大致消耗10ms左右的时间检索完毕。
但是算上ToLower的时间后，消耗的时间就变成了4807 ms了。

可以说光是做ToLower的操作，就够你算法核心的本身处理将近500遍了。与其在fastCheck上面空间换时间，还不如做这一个优化呢。由于你现在并没有作HashCode优化，所以我建议你不必做HashCode优化了，撑死了你也只能优化出10ms的时间来。

@楼主：
根据我的测试，下面这段话是有Bug的，能否说一下他的含义：

if ((fastCheck[current] & 1) == 0)
{
++count;
}

我是没有明白，为什么如果在检索的时候发现某个字符不在脏字表中的起始符，就可以将“跳跃字符数”加1？
比如说脏字表：
ABCDE
JCKED
BC
CE
待检文本：
ABCEDXX
当扫描到A的时候，就会进入扫描过程。接下来会扫描
AB
ABC
ABCE
ABCED
但是由于E和D都不在脏字表的第一个字符里面，因此会导致++count执行两次，最终count==3
那么下一个扫描的字符就变成了第4个字符E，这样的话BC和CE都没有机会被扫描到。这是我和你的扫描结果不一样的另外一个重要原因。我把这段话去掉之后，部分的解决了问题，但是仍然有无法正常匹配的情况。我会给你寄一个简单的样本，你如果有兴趣，可以测试一下。

另外我今天才发现，我和你之间的速度比较是有点不公平的，因为你的算法是大小写敏感的，而我的算法是大小写敏感的。大小写敏感加上去之后，速度会变慢很多的，你可以试试。

这个……确实不好意思，因为我们对断字的方法不一样，我这边会根据空格作为分隔符，所以会有“法”这个词。
抛开这个不说吧，因为这个也许会有点争议。但至少目前打开脏字表文件本身来检索，其繁体字的台X，X湾什么的，有好几个是没有被检查出来的。

@楼主：
呵呵，有失风度的地方多多包涵。不过380 vs 298 的原因我看了差异了，确实是没有检索出来。比如“功”这个单字就没有照出来，另外用您的算法查脏字表本身，确实是有条目没有被查出来。

如果我有表现出来不屑，首先道歉，其次解释一下，确实没有这个意思。这么说吧，我个人认为，如果说有两种算法，空间复杂度近似，比如说O(c*m)和O(1*m)，这种就可以认为是类似。那么在类似的前提下，效率不同，那就是算法的功劳。否则，比如说我们的脏字检索，如果通过开通更大的映射表来解决效率问题，确实有可能提高，但是这样的提高就不能体现这个算法的优势了。原因很简单，两个不同的算法，通常都有可能通过增加内存消耗，来提高效率。

换个比方吧：比如我们的机器，我想如果比较1个AMD的CPU和1个Intel的CPU有什么差异，这个比较值得研究。但是如果讨论变成了：我这个装AMD CPU的服务器，原来只有1个CPU，现在我加到8个了，所以变得很快……这个讨论起来感觉就有点那个了，因为你肯定也会像，那我加几个Intel CPU，不也一样能够更快吗？Money换Time嘛。

另外，你原来那个版本的算法确实是很好啊，我没有想要非争个你高我低，面红耳赤的。我之所以要跟你的算法作比较，无非也是想要找一个更优秀的算法。如果说你的比我的更快，我会这么处理：
1、思考为什么我的思路会更慢；
2、采用你的方案。

前提是，你的算法确实正确。目前问题就在这里了：得到的结果确实是不正确的。

PS：等你的算法能够检出脏字表文件里面的所有条目，我会再测一次，到时候可能你的代码会不一样，到时候我们再分析一下思路上的差异导致了那些结果上的差异。现在我们争论太多也不会出一个结果的，对吧？

@楼主：
算法不稳定啊……
同一篇280K左右的文章，我匹配出380个，你的算法只匹配了298个，相差太多了，上一次出错是什么原因找到了没有？这样的情况下所获得的性能提升，很可能是以没有匹配出应有的东西为代价的。如果都匹配上的话，说不定要补充一些语句，是否会消耗大量性能就不好说了。有句话叫做20%占用80%的资源，所以如果我们两个算法之间的匹配数量差异超过10个，那么性能上的比较就没有意义了。至于你算法里面到底什么地方导致某些单字没有被检索出来，我一眼没有看出来，我想还是你查一下比我快。我这次不打算给你发报告了，因为我发现你的算法目前连脏字表文件都没有全检出来，你可以试一下通过这个来看看算法到底为什么丢了一些匹配。

同一篇文章，目前你的这个算法用5ms匹配298个条目，我需要用19ms匹配出380个条目。不知道等你的算法稳定后，是否还是这个数值。

另外，目前你的改进基本上主要还是动用“空间换时间”的思路，算法上可以说没有性质上的改进。因此，我没有太大的动力来改进自己的算法效率，因为你通过空间换时间，我也一样可以空间换时间。

我怎么看上面有人理解为:
递归的速度比迭代要快？比如就有人列举汇编结果，认为递归的代码更简单，运算量更小，所以更快。也许我理解错误了，但是反正有不少回复给我的感觉就是如此。

事实上这种理解是错误的，因为以C语言的结果为例，在几乎相同的时间下面，递归只算了10遍，而迭代运算了26925370。这么说也许还是不太清楚，这么说吧：
假如一颗导弹上面的导航系统，恰好要算Fib，每秒钟计算次数越多越精确，你觉得用递归的导弹好呢，还是迭代的导弹好？
要我我用迭代的。

列出汇编的同志说，如果递归使用缓存可能更快。确实应该更快，但是事实上，如果使用了缓存，也就等同于迭代中的对a和b进行赋值及取值。同样的，迭代也可能存

在更好的优化方案。因此这种最终是否能够优化得跟迭代一个数量级，很难讲，而且优化之后，是否还能保持原来所谓的“可读性”优势，也很难讲。可读性本身是一

种无法简单衡量的问题，古人读古文就很可读，现代人读古文就很难读。关键在于一种写法对于读的人来说，是否熟悉。大多数人读迭代容易还是读递归容易，我觉得

很难说。对于你我来讲，可能都差不多，一看就知道什么意思了。对于初学者，也许递归更难理解一点。

对于楼主，你的这个比较很有意思。但是写的却是有点误导别人，为什么这么说呢？按照我的理解，你的分析过程分为如下三个步骤：

1、也许你一开始，想要比较递归和迭代的差距。
2、后来发现差距挺大的，就假设是调用引起的，于是让大家都进行了同样多次的调用，试图抹去call操作引起的差别。（其实这里已经偏离了你原来做本次试验的目标

——检验递归和迭代之间的差距，因为你抹掉了call差异的同时，扩大了其他运算量的差异！）
3、最后发现结果和想象的还是不一样，才找到运算量的差异。

第一步的问题其实很简单，本来就是递归比迭代要费时间。简单的时间复杂度分析即可得出结论。
第二步的试验目的就是抹去call操作引起的差别，结果出来之后，还是不能够自圆其说。
第三步，发现了运算量差异，但是没有说明白，或者可能没有想明白。

其实应该是这样的，参见最后一张表：
递归 迭代
赋值语句 3 120
变量分配 2 4
函数调用 2 0
返回 2 2
条件判断 1 30
跳转 1 30
累计 11 186

其实这么一张表是非常有误导性的，因为递归的一次调用，只是计算一次斐波纳契数列所需要调用的N次Fib()中的一次调用。
而迭代的数据，则是计算一次斐波纳契数列的所有运算量。
这跟用一颗子弹和一颗原子弹的制造成本，来评估他们的作战成本一样。

事实上，迭代方法所做的运算总量，减去递归的运算总量，剩下来的是26925370 - 10=26925360 次的除了Call操作之外的迭代运算。
而试演的最终结果，也能说明好几个问题：

1、通过C的运算结果看，call操作造成了极大的性能损失（损失了26925370次迭代运算的时间），为什么？
因为Call操作会中断CPU的分支预测过程，因此虽然Call操作数量一样，在同等甚至更少的时间内，迭代运算多计算了26925360次的Fib(30)！

2、通过C#的运算结果看，迭代比递归多出来的时间倍数，和一次调用的运算量差异几乎成正比。也就是说，C#的迭代比递归“慢”，
是因为每次调用的运算量差异。实际上，如果我们比较每次Fib运算，还是迭代比递归快很多的，即使是C#。

3、通过C和C#的对比发现，在递归时，由于大家在CPU分支预测上的差异相对较小，而迭代时双方对分支预测的效果差别会比较大。
如果你看过C#程序的实际机器代码，就会发现他里面会夹杂不少的Call操作，用来比如说判断是否超界等，具体这个例子如何，不太清楚。
因此很可能C#的性能损失发生在这里。

反正我得出的结论和大家的不太一样，不知道是否有不对的地方，请指正。

咳咳，楼上有欠文雅
最近不怎么写了，太忙

北京电信 1M （可能是楼层共享10M）
晚上19：30
50~110KBytes/sec
IE下载

不错，看来比原来肯定好很多。

指数期货是有做空个股的作用的！
你沽出一份期货合约的时候，相当于你把一份股指期货“卖”给证交所，这相当于证交所买入一份期货。而证交所为了不亏本（同时也不赚钱），就会在现货市场卖出相应的成分股股票！
当然，不在成分里面的个股不受这个作用的直接影响。但是试想整个大盘都在跌，谁敢买个股，尤其是那些小盘的个股？

@dudu
说实话，我对博客园在什么地方不太感兴趣，而且我觉得这样的讨论也是在浪费精力。

通常有这样的提问，应该是提问者心中已有定见，但是又有犹豫不决，想要从其他人的回复当中寻求支持——至于不一样的答案，可能会忽略不计。

如果我没有猜错，dudu应该是有离开北京的想法吧？如果是这样的话，无非几个方面：各项运营成本高；离家较远等私人原因；人才问题得不到解决而恰好有其他地区的人发出邀请。

其实博客园在那里对我来说有一样，而近几年我在北京，对附近的一些情况稍微清楚一点。

那么假设留在北京：
1、运营成本问题：
服务器如果放在天津，成本会减少至少1/3，只是一旦硬件出问题，需要驱车前往解决，时间上的问题稍微难以解决。我瞎想了一下，如果博客园在天津有个办事处，可以解决这个问题。（难度还是有点大）
至于人员，初期只能够忍忍，相信哪一个城市都是一样的，直接的因素无非是无价水平的高低。但是不要忘了，招人本身也是一种成本，如果长时间无法找到合适的人选，也是一种损失。一般来说稍微大一点的城市都不是问题，上面列出的北京、上海、广州、深圳、珠海、杭州、南京，我想都不会存在极大困难。但是无论哪一个城市，初期都不好找。
开发成本，可以通过部分的OpenSource，或者第三方服务插件的方式得以解决。这个最终看投资方是否同意了，与城市仍然无关。
搬迁成本，不要忘了，搬迁到其他城市也是一种成本。首先服务器要运来运去，人员要安顿。等重新稳定下来了，估计至少一个月过去了。那么这一个月的人员工资，落后了的进度，都是极大的成本。
机会成本，不要忘了，新去的地方有可能更好，也有可能更坏。要考虑到，当前的那些优越的条件，一旦你搬走了，那就首先要放弃这些。至于你新去的地方如何，是机会问题，说不清楚的。

2、至于私人问题，我觉得这就无法回答了，各人有各人的衡量。我表示尊重。

3、至于说有人邀请的话，那还是要考虑前面成本的问题。各人觉得，邀请对方过来是更好的做法，除非对方真的是巨牛无比的人。想必有热情的人应该能够被吸引过来，没有热情的话如何熬过最开始的这一段时间呢？也许对方也有不得已的理由吧，我还是不做过多的评论了。


反正就我目前对商业化的理解，最好是坚持，初生的企业是经不起折腾的。

由于你用的是C++编译器命名约定，所以才会后面有一大堆乱七八糟的字符串（用来指示有多少个参数以及他们的类型，说白了就是方法签名Method Signature）

不过非常抱歉，具体应该怎样正确导出我已经忘了。
可以试试用extern "C" 来修饰，好像更加准确的方法是用一个特殊的描述文件来描述，忘了忘了，老了……

@周鹏:
现实不是像当然能的就跟理论一致的。当年Waterfall的理论是那么的完美，也有很多公司严格按照这一套来搞的，最后有多少搞砸了大家现在都知道了。Waterfall的理论不就是为了管理和控制整个项目的周期的吗？照您说的，哪些搞砸了的公司都是说明那些人没有用好？

其实设计模式和框架也是一样的，理论上确实如此。但是实际上Waterfall忘了考虑需求的变化，所以有缺陷。设计模式和框架也一样的，理论上的好是建立在所有人都假设能够很熟练的，并且是正确的应用这些东西的基础上。水桶理论知道吧？一个桶能够装多少水，取决于最短的那块木板。如果你硬凑木桶的最高高度，而不考虑最短的那几块木板，你注定是在浪费公司的资源，浪费大家的感情。

我想你还没有仔细看看我另外一篇Blog吧？
http://www.cnblogs.com/sumtec/archive/2007/04/12/710745.html
你如果看了还是这么认为，我就无话可说了。

我并不是说这些模式啊，设计啊没有用，而是很多时候你没有办法用，因为有短木板的存在。你用了不仅仅是白搭，而且你应该知道这些设计精良的东西，是经不起短木板的摧残的！一旦被那些短木板胡乱改一气，你真是哭笑不得。

别的不说，我举一个非常简单而又真实的例子：我们框架里面就有权限检查的工具，只要在需要的地方加上一句简单的调用就可以实现。但是偏偏就有人懒得写上去！你总不能期待搞出一个框架，能够什么也不写，什么也不配置就能够自动分配权限吧？你总得要配置哪些页面需要检查权限而那些不用吧？

其实我们系统里面防线足够多了，从上到下，随便哪一个地方都可以拦截，偏偏这个页面就是一道防线都没有架起来。大公司就免谈了，不在我讨论的范围内。

天晓得短木板会不会为了某个调用比较方便一点，把权限系统里面的某个检查代码给短路掉，这是需要担心的事情。

3、就在最近，我刚装上的Vista突然自己崩溃了，虽然我会写很多程序，但是Vista崩溃了我也没有办法，我朋友给我介绍了一个高手来帮我修电脑。

他看了一下电脑，问我有没有Vista的安装盘，我说没有。

他想了一下，叫我拿一根没用的网线和一把剪刀，我想修电脑要网线和剪刀干什么，但人家是高手，我也不好说什么，就拿了一根没用的网线和一把剪刀给他。

他把网线一头戳到网卡上，剪断另外一头，然后就在哪里不停的拨弄那八根线。他拨弄的速度非常快，但是拨弄得线总是不一样，我搞不懂这有什么用，但也不敢问，看了半个多小时，他还是不停的拨弄着网线。我渐渐的有些困，我问他这东西要搞多久，他说要几个小时，我给他倒了杯茶，就一个人去隔壁睡觉了。

醒来的时候，一看已经过了4个多小时，我起身到隔壁，看见他正在Vista里面调试，还装给装好了Visual Studio 2005 Team Suit、Ms SqlServer 2005 Enterprise Edition、BT，还边下载边看American片……过了一会儿，他惊觉我站在后面，不好意思地对我说，你试试。我坐上椅子用了一下，真的好了，我当时太震惊了，整个人傻在哪里，谢过人家就走了。

后来我读到了前面那两篇文章，终于醒悟，原来当时那位高手是用网线模拟网络启动，下载了整个Vista，还有Visual Studio 2005 Team Suit、Ms SqlServer 2005 Enterprise Edition、BT，以及他正在看的American片，我后来问我朋友那位高手的下落，我朋友说前几年去了美国之后，杳无音讯了十几年，期间也回过中国两次，最近这一次回来说，干这个太没意思了，回来收拾收拾准备去阿尔法半人马座，他说他也听不懂那高手说什么，只是最近传闻微软的Vista全世界都无法激活，估计跟他的离去有关，当然了，这几天也是杳无音讯....

貌似是比较强

@温少
希望有更多类似
http://www.cnblogs.com/jobs/archive/2006/09/22/512297.html
这样的帖子出现，这种帖子比较合我的胃口，相信也比较合大家的胃口。

@所有人
俗话说得好，我不做苍蝇，谁做苍蝇。看着引苍蝇的贴子引来一片打苍蝇的，感觉真的很浪费大家的精力和感情。

我真心希望站在.NET这边的同志让其他.NET同志以你为荣，而不是为耻。
我真心希望站在.NET这边的同志让Java同志尊敬你，而不是鄙视之。
我真心希望站在Java这边的同志让其他Java同志以你为荣，而不是为耻。
我真心希望站在Java这边的同志让.NET同志以你为荣，而不是为耻。

@温少
貌似人身攻击是不道德的行为。
貌似动怒对肝不好。
貌似如果有人对着帕瓦罗蒂说他唱的很差，他也不会立即对那人高歌一曲。
貌似跟别人对骂会把自己的水平变成和别人一致，可能是提高也可能是降低。
貌似说点正事比开这样引苍蝇的贴要积极一些。

我发的帖子是希望停止一些不良的事情发生，比如无谓的争论工具的好还是坏，无谓的做人身攻击和谩骂。我也希望自己是绅士能够做到这几点，不知道温少是否同意。如果同意，是否可以停止这种挑事的帖子，对大家的进步貌似没有帮助。

@温少：
我的文章不针对任何个人，只是想说明一些问题。至于各人看后有何想法，我不可能强行要求。当然了，各人看完每一篇回复，也会有不同的想法。争取绝大多数认同，是我的目的。不是有一首歌，歌词道“缤纷色彩闪出的美丽，是因他没有分开每种色彩”。另外我也知道“当食指指向别人的时候，另外四个手指是指向自己的”。所以我也没有说谁丢人，文章题目只不过是博取一下点击率。如果说真丢人，那也是我自觉自己打自那时起就没啥长进而以。如果大家非要有不同的解读，我也无法限制，对吧？

@david.turing:
不讨论windows和其他系统之间的直接比较，但就差距而言，这么多年来感觉应该是缩小了的。
我记得几年之前，使用Windows操作系统的“服务器”（貌似还是WinNT），居然传说每个礼拜都得要重启，否则后果就是说不准哪一天自动重启。
现在嘛，个人感觉至少没有那么糟糕了，对吧？
相对于Unix系统来说，单价应该便宜一点。相对Linux来说，支持应该好一点。
至于你要性能，还是要便宜，还是要服务，还是综合考虑，那就是你的事情了。所以每一个人的决定都不一样，不足为奇。

@灵感之源：
十一见吧！我十一回广州，到时候抽一个时间如何？给我你的手机号啊，木有手机号，回了广州也找不着你。发我邮箱如何？

@Anders Liu:
我不是针对你呀，我是针对有一些回复里面越来越浓烈的火药味。
当然了，你也别挑事嘛！本来这种事情一折腾就会有N多双方阵营的出来辩论，其结果不是促进社会和谐……
看来你那个带三块表学新先进性教育的工作没有做好，以后要努力学习小胡同学的和谐博客理论……
(@dudu：小胡同学是我同事啦，不要把我的回复咔嚓掉，谢谢！）

还是@Anders Liu:
不过话也说回来了，也要赞一下你的文章，我从里面的回复知道了很多现在.NET的实际应用案例，增强了使用.NET的信心（原来也很有信心，现在是太有信心了……啊，要骄傲了，谁来扇一下偶？）

一般你说的的这个CPU100%，要花很长时间的问题，通常是正则表达式写的不好造成的。比如说探索深度过甚等，建议对表达式进行检查，进行必要的修改（通常是剪枝、提括号和调整顺序）。

对于这段代码，有两个改进的建议：
1、用t.Join(timeout)可能更好
2、建议作一个能够执行Timeout操作的辅助工具类比较好，因为这种类似的问题是一个比较通用的问题，不仅仅存在于Regex。而且现在这样封装的类，可能无法提供完整的Regex功能。

估计大家都应该看过一条类似这样的法则：
不要在代码中嵌入汇编。（比如用的是类似C的语言）

可是问题是，这样的法则不适用于开发操作系统的团队。

同样的，这样的法则实际上只能够适用于做一些小型的，不需要一些很复杂逻辑的网站。对于大型复杂的网站，这些法则几乎完全没有价值。前面已经有人举例说明，像类似Ajax的功能就无法不通过javascript生成Html。我也不明白在需要Binding的时候，如何不使用<%符号。当然，完全可以在code里面写Binding，但是这样的代价是非常巨大的。实际上不写<%在一般情况下，是可以提高维护效率，比如我只是想要换一个色系。但是实际上如果我们需要多显示一列怎么办？你只能够改代码，所以维护效率不见得总是很高。而且这么做实际上是牺牲了可维护性，因为如果在Aspx里面通过<%来描述那一个地方显示什么内容，是一件一目了然的事情。但如果在代码里面来做类似的事情，则是一个相当不直观的过程。当然了，也有办法能够同时避免这两个问题，但是开发量就上去了。再者，实际上你也不可能指望Designer用DreamWeaver能够把
因此做复杂网站的时候，通常都会对大部分页面采用<%来描述。

确实是根据上述文字处理的。事实上我测试过很多遍，都没有出现过任何问题。

@xblues
看来你对博客园的发展是毫不关心，没有dudu为我们做那么多的贡献，你能在这里发表不经大脑思考的言论吗？我现在也只是希望能够尽我所能，替dudu分担一些，也让大家能够就这样的事情多讨论一下，看看能不能集思广益。你如果觉得浪费时间，那也请你不要搅场。

@dudu
也许这样的人确实很难找，暂且按下不说。那么首先也应该确定一个良好的商业计划，否则很难有适任的人选愿意加入到管理团队当中，仅凭热情加入的人还是非常少的。

@rexsp
Thanks, fixed.

@dudu
我所说的团队可能是更具规模的团队，不是核心人员。而且我真的看到了一两个具有强大执行能力的人，在项目开始的初期有效推动项目的进行。所以如果有这么一个关键性的任务存在，那么比什么都重要。或者说，有这样的人，哪怕是垃圾都能够卖出去（只不过是价钱的问题了）。

要吸引这样的人，那么一定要有很好的商业计划，因为通常他们应该已经是比较有钱，不缺钱花得了。他们之所以向加入，多半是为了梦想或者说是成就自我。（有人说得不好听叫做没事找事做，当然我不这么认为啦。）甚至如果你的计划很好的话，还是有可能给你投入初始的启动资金。并不是每个人都有这样的机遇和能力，能够与这样的人共事，但至少我看博客园至少有这样的希望。

资金还是很后面的事情，好东西不怕没人投钱。

P.S.: 我最近还是时间不多，要不是看到关乎博客园发展的文章，我还真挤不出时间喘口气呢

这两个例子的性能估计可能不会相差太大，因为C#的switch实际上是查表的，不是一大堆的判断语句。

@idior
我猜测 static readonly 那边的初始化应该是整个进程锁定的，理由很简单，static readonly 的变量应该是在class构造的时候进行的。当第一次使用某个class的时候，构造的顺序应该如下：
1、static 变量初始化
2、执行static 构造函数
3、开始父类的构造过程
4、class 全局变量初始化
5、执行实例构造函数

其中3-5步是以后每一次构造一个实例的时候所经历的步骤。
从上面这个过程可以看出，如果static readonly（其实不是readonly也一样）的变量初始化过程不是线程安全的，那么后面的构造函数也必然存在执行多次的可能。然而如果static构造函数能够执行多次，那么可以肯定很多程序会变得非常不稳定，甚至存在资源泄露，尤其是一些非托管资源。比如说在static构造函数里面打开一个文件并赋值给一个static变量，或者发出一个互斥体信号等。

所以说，按道理来讲，第一次使用某个类的时候，一定会先锁定这个类的Handle，使得其他使用这个类的线程不会同时进入这个类的静态初始化过程。

只有答案没有过程，要是面试的话就等于没有回答哦！:)
而且这么问有一个小小的瑕疵——你问的两个问题有一个字不一样！

@ccBoy:
我也没有办法啊，上来的时候老板已经装好了SharePoint Portal 2003了，注意，是SharePoint Portal 不是Service，而且SQL Server 2k5 也已经装上去了，还不是默认实例。所以我也没有办法啊，都到这个时候了，我就懒得再去看什么安装文档了。更何况要求就是要装在原来的这台服务器，而偏偏这台服务器他就是不干净的：已经有一个默认实例的Sql2000，以及使用这个默认实例的一个非默认站点，但是IP地址又偏偏是“全部未分配”。那这种情况也就只能够这么折腾了。

至于你提到的中英文混装似乎没有任何问题，主要是多打几个补丁，装一个Language Pack，没有产生问题。唯一让人郁闷的就是那堆问号，不过用Reflector也发现问题所在了。哦，还有一个比较郁闷的，就是操作系统是中文的，事件记录里面的中文错误不知道对应的具体英文是什么，没法搜索。

有人说了，可以弄一台干净的机器，或者在虚机上装一遍，实际上这毫无意义。如果搞理论研究，或者装着玩玩，那是好办法。可是我们这里是要实战使用，而且要求就是要在这台不干净的机器上面装。在干净机器装一遍肯定成功啊，但是成功了之后还是得要到这台不干净的机器上面装，该是装不过去的地方还是装不过去。所以之前的安装根本就是浪费时间和感情。

@问 题 男:
哦，没有注意。受教了：）

@FellDesign:

跑过100米吗？那是打一开始就要冲刺的。
跑过马拉松吗？那是打一开始就要省着点。

你觉得一个程序的开发是跑100米呢，还是跑马拉松？要是以跑100米的方式跑马拉松，100米之后不是会不会慢下来的问题，而是会不会口吐白沫的问题了。

其实人就是人，始终不是机器。你让人加班，那个人是不是确实在加班就已经是一件比较难以保证的事情。嗯，可以加上非常严厉的规则，例如中兴华为那样，是可以保证确实在加班，可是质量呢？好吧，加上严格质量审查——其实这个本来就要上的，但是在高强度的工作环境里面，出错的纪律自然比低强度状态下药膏（假设其他所有条件都相同的情况下），那么你能做的就是更加严厉的考评制度：做不好就扣奖金，扣完奖金扣工资。要是这样，我倒要问问看，公司打算跑完100米就拉倒呢？还是想跑时间长一点？这样的工作环境，一流的人才肯定呆不了多久，顶多合同期到期，肯定得走人，除非你发的工资足够高。否则估计用不了多长时间，你就会发现，留在公司的都是二流三流的人。都是二流三流的人所组成的公司想要成为一流，而且能够维持一段时间，那就比较困难了。

刚查过了，确认.NET背后的机制就是IOCP（个人认为）。用Reflector看System.Threading.IOCompletionCallback的callee，可以看到这么一条调用链：

System.Threading.IOCompletionCallback
Depends On
Used By
System.Net.Sockets.OverlappedCache..ctor(Overlapped, Object, IOCompletionCallback, Boolean)
Depends On
Used By
System.Net.Sockets.BaseOverlappedAsyncResult.SetUnmanagedStructures(Object) : Void
Depends On
Used By
System.Net.Sockets.OverlappedAsyncResult.SetUnmanagedStructures(Byte[], Int32, Int32, SocketAddress, Boolean) : Void
Depends On
Used By
System.Net.Sockets.OverlappedAsyncResult.SetUnmanagedStructures(Byte[], Int32, Int32, SocketAddress, Boolean, OverlappedCache&) : Void
Depends On
Used By
System.Net.Sockets.Socket.DoBeginReceive(Byte[], Int32, Int32, SocketFlags, OverlappedAsyncResult) : SocketError
System.Net.Sockets.Socket.DoBeginReceiveFrom(Byte[], Int32, Int32, SocketFlags, EndPoint, SocketAddress, OverlappedAsyncResult) : Void
System.Net.Sockets.Socket.DoBeginSend(Byte[], Int32, Int32, SocketFlags, OverlappedAsyncResult) : SocketError
System.Net.Sockets.Socket.DoBeginSendTo(Byte[], Int32, Int32, SocketFlags, EndPoint, SocketAddress, OverlappedAsyncResult) : Void

说错了不要扔板砖啊，大过年的。

如果我没有记错的话，.NET里面的很多异步IO，背后都是用的IOCP的。也就是说，用BeginXXX/EndXXX实际上应该就是使用的IOCP。不太记得了，我要查一下。

建议先发简历过去，有一定的可能性。

待遇问题估计属于HR负责，具体请自行联系。（现在的招聘也没有哪几家会直接说待遇的吧？待遇如何跟个人水平还是有关系的。）
我只是代发，无法回答更多的问题，还是那句话，请自行联系。

：）