sudo ltrace -o outlog node myTest.js
这是不是你想要更多的可能性。在我的机器上翻译成Date.now()
的电话是clock_gettime
。你想看看后续调用clock_gettime
之间的东西。你还写出了STDOUT,每次你有这样的开销。您可以运行ltrace
下的整个流程以查看发生了什么并使用-c获得摘要。
对我来说,它运行在3毫秒,而不是在ltrace下运行它。
% time seconds usecs/call calls function
------ ----------- ----------- --------- --------------------
28.45 6.629315 209 31690 memcpy
26.69 6.219529 217 28544 memcmp
16.78 3.910686 217 17990 free
9.73 2.266705 214 10590 malloc
2.92 0.679971 220 3083 _Znam
2.86 0.666421 216 3082 _ZdaPv
2.55 0.593798 206 2880 _ZdlPv
2.16 0.502644 211 2378 _Znwm
1.09 0.255114 213 1196 strlen
0.69 0.161741 215 750 pthread_getspecific
0.67 0.155609 209 744 memmove
0.57 0.133857 212 631 _ZNSo6sentryC1ERSo
0.57 0.133344 226 589 pthread_mutex_lock
0.52 0.121342 206 589 pthread_mutex_unlock
0.46 0.106343 207 512 clock_gettime
0.40 0.093022 204 454 memset
0.39 0.089857 216 416 _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E
0.22 0.050741 195 259 strcmp
0.20 0.047454 228 208 _ZNSt8ios_baseC2Ev
0.20 0.047236 227 208 floor
0.19 0.044603 214 208 _ZNSt6localeC1Ev
0.19 0.044536 212 210 _ZNSs4_Rep10_M_destroyERKSaIcE
0.19 0.044200 212 208 _ZNSt8ios_baseD2Ev
我不知道为什么在那里有31,690个memcpy和28544 memcmp。这似乎有点过分,但也许只是JIT启动成本,至于运行成本,你可以看到512个调用clock_gettime
。不知道为什么有那么多的电话,但你可以看到在clock_gettime
丢失106ms。祝你好运。
尝试将输出重定向到文件以查看是否使事情变得更快。尽管我怀疑有什么可以做的,以防止它。至少在OS X上,由于小I/O缓冲区大小,控制台的“stdout”可能会被阻塞,也许在Windows上也会出现类似的情况。 – robertklep