多线程:JavaScript的性能陷阱
Tuesday, September 12, 2006 5:16:01 AM
JavaScript没有提供非常强大的多线程技术,但这并不是说JavaScript纯然是单线程的。
Ajax提供的多线程机制会让开发者留心执行某些代码的时机,从而能够正确地运行程序。
但一些隐蔽的多线程,则不幸地成为开发者的雷区。
例如:
call_a_function();
call_another();
call_another()一定会在call_a_function()完全完成后才执行吗?
不一定。尤其当call_a_function()一连串地调用一个又一个的函数时,这种顺序执行的假设就容易引起错误。
另一个不幸的消息时,这种错误有时——甚至于在调试阶段的大部分时候——都没有浮出水面,然后,客户怒不可遏地反馈了错误。
从程序的健壮性的角度来看问题,代码级的运行时检测有时比算法更重要。
另一个陷阱是:原本期望call_another()在call_a_function()完成后马上调用,并且假设这根本不会影响性能。
还是假设上一种情况,当call_a_function()一连串地调用一个又一个的函数时,call_another()的执行会比想象中、可接受的延后要迟得多。
绕过这个陷阱的不二法门是能做的就尽量早点做。
It works.
It works well.
It works perfectly.
这是三种完全不同的情况,其间的差别可能是万种风情。
JavaScript的门槛很低,但JavaScript的确比一般人以为的难,JavaScript更是比一般人想象的更强大。
Ajax提供的多线程机制会让开发者留心执行某些代码的时机,从而能够正确地运行程序。
但一些隐蔽的多线程,则不幸地成为开发者的雷区。
例如:
call_a_function();
call_another();
call_another()一定会在call_a_function()完全完成后才执行吗?
不一定。尤其当call_a_function()一连串地调用一个又一个的函数时,这种顺序执行的假设就容易引起错误。
另一个不幸的消息时,这种错误有时——甚至于在调试阶段的大部分时候——都没有浮出水面,然后,客户怒不可遏地反馈了错误。
从程序的健壮性的角度来看问题,代码级的运行时检测有时比算法更重要。
另一个陷阱是:原本期望call_another()在call_a_function()完成后马上调用,并且假设这根本不会影响性能。
还是假设上一种情况,当call_a_function()一连串地调用一个又一个的函数时,call_another()的执行会比想象中、可接受的延后要迟得多。
绕过这个陷阱的不二法门是能做的就尽量早点做。
It works.
It works well.
It works perfectly.
这是三种完全不同的情况,其间的差别可能是万种风情。
JavaScript的门槛很低,但JavaScript的确比一般人以为的难,JavaScript更是比一般人想象的更强大。
