用手写识别试了下，语言是泰语，标题打出来是 ประกาศจับ，剩下的应该好解决了

本来想说些什么的，但有些东西只有你经历过才能有体会，不经历过说了也不能完全理解，经历过不说也会明白，所有我只能建议楼主，从今天开始，在程序的重要步骤，检测到异常输入的时候，进入了不大可能进入的 else 语句的时候，用 logging 模块打印状态信息，包括现在正准备或者已经做了什么，和关键变量的值。等楼主这么做一段时间之后，自然就明白了。

说真的，晚上不按时休息，对身体有很大的影响。

是不是和 <embed> 标签有关？如果是的话，可能就是我以前遇到过的一个问题。

以前遇到过拖动滚动条的时候，网页不能正确重绘的现象，截了图，还把出问题的网页打包做附件放上去，还找出了是哪个标签导致了 bug，提了 issue。石沉大海两个月后被 close as we can not reproduce 了。

相比之下，给 github 上的活跃项目提 issue，一般都是几个小时内开始处理，几天就 fix 的。

OLE, ActiveX, COM+, DNA, .Net, Silverlight, TypeScript.

微软的承诺从来没有兑现。

谢谢分享。gethostbyname 万恶的地方就在于它是阻塞的。

@fanzeyi 看我 5 楼的结果，gcc O2 + no-optimize-sibling-calls 比 jvm 快。对这个递归，就相当于是遇到了 optimize-sibling-calls 的 bad case 了……

@fanzeyi

fibonacci 的 divide and conquer 算法通常是用来演示 divide and conquer 的 bad case 的……我想原文作者拿它作为测试不同语言的一个有趣的方法再合适不过了

@fanzeyi

连你的错误一起 copy 了……

http://gist.github.com/3798325

打开或关闭 -fno-optimize-sibling-calls 开关，两种不同的优化方式，导致速度相差一倍以上，一种比 JVM 快，一种比 JVM 慢。

https://gist.github.com/3798298

C 加个 inline 之后：

$ gcc -O2 -s test.c && time ./a.out
102334155

real 0m0.679s
user 0m0.678s
sys 0m0.001s

$ gcc -O2 -fno-optimize-sibling-calls -s test.c && time ./a.out
102334155

real 0m0.337s
user 0m0.335s
sys 0m0.001s

$ time java test
102334155

real 0m0.524s
user 0m0.535s
sys 0m0.017s

占座能让你胜人一筹，却让一半的座位处于被东西占着，不能使用的浪费状态。

Hibernate 都能用成这样，佩服。

分几个阶段吧。

1. 了解基本语法。
2. 学习 DOM API，做一些练习。
3. 理解 prototype, first class function 和 lexical scoping。
4. 读一些优秀项目的源码，如 jQuery。

@zhangxiao 线程或者 aio。磁盘读写不像网络连接，不需要并行化，每个磁盘一个线程，控制队列长度就可以了。

@csx163

涉及到显示或者网络的性能的时候，你真的不能怪语言。这个纯粹看设计的原理。

Android 以前慢，是因为它不缓冲已渲染的部分，每一帧都重绘改变的了 rect，就像 Windows 的古老做法一样。你可以回忆一下引入 DWM 之前，Windows 上快速拖动一个窗口，特别是比如在打开了一个复杂文档的 Word 窗口上方拖另一个窗口，CPU 耗光，下面的窗口却来不及刷新的情景。ARM 比 x86 慢一到两个数量级，在 ARM 上用重绘去实现拖动，帧率自然很低。

cocoa touch 是苹果最 NB 的东西。它好像是最早在手机上把硬件加速广泛用在 UI 框架上的吧。把 CPU 从平移、旋转、缩放中解脱出来，往下拖动的时候只渲染一次下面的内容，再把它一点点往上挪，自然优于每一帧都重绘。

iOS 上有不少写的很烂的 App，拖动的时候卡的要死，一看就是每一帧都重绘的。

这不代表 Windows 以前用重绘就不对。因为以前内存和显存有限，重绘是唯一的选择。

@akann 嗯。而且虚拟化的解决方案本身相比物理服务器也有些贵。初创公司可以用云服务验证一下产品原型，一些小公司和个人可以在云端上面挂个主页，但互联网的 big player 们，一定是要自己搭建服务器的。从这点上看云平台承诺的 scalability 到最后还是不如 DIY。

推荐读一下 http://www.remlab.net/op/nonblock.shtml

Regular files are always readable and they are also always writeable. This is clearly stated in the relevant POSIX specifications. I cannot stress this enough. Putting a regular file in non-blocking has ABSOLUTELY no effects other than changing one bit in the file flags.