TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Hello World execution time

87 点作者 sheffield将近 14 年前

15 条评论

yason将近 14 年前
Interesting but correlates with the number of files and libraries the interpreter must read or parse. Anything that's quite self-contained is fast; anything that needs to look up and read lots of files is slow.<p>All I can say is that Java startup time is abysmal. Still, and after fifteen years. Java was dead slow in the 90's and it's dead slow these days when compared to anything else. I love Clojure but Java startup time rules it out for anything else but long-running processes or, when coding, using repl via swank.
评论 #2698938 未加载
评论 #2699405 未加载
评论 #2699274 未加载
评论 #2698904 未加载
评论 #2698839 未加载
评论 #2710354 未加载
评论 #2698850 未加载
评论 #2698984 未加载
loganlinn将近 14 年前
In a reply, he adds Haskell (compiled with ghc)<p><a href="http://lists.nongnu.org/archive/html/chicken-users/2011-03/msg00090.html" rel="nofollow">http://lists.nongnu.org/archive/html/chicken-users/2011-03/m...</a>
ronnix将近 14 年前
The Python interpreter does an implicit "import site" on initialization.<p>You can disable it using the -S option if/when you care about startup time.<p>Here are some numbers on my MacBook Pro:<p>$ ./run.sh bash hello.sh<p>median 0.002<p>$ ./run.sh python hello.py<p>median 0.016<p>$ ./run.sh python -S hello.py<p>median 0.008
burgerbrain将近 14 年前
Unless I'm mistaken, the "Bash" benchmark is actually just measuring the amount of time it takes a C program to read an argument and print, instead of just a C program printing.<p>Assuming the bash program was: `echo "hello, world!"`<p>Edit: I likely am mistaken. Chances are this was done using the builtin 'echo', not '/bin/echo'. The builtin is always faster (though putting them in a file (as is the only fair way to do it) slows them both down of course).
评论 #2698992 未加载
retube将近 14 年前
I guess java is so slow because you have the initial over-head of starting the jvm. I'm guessing that subsequent prints of "Hello world" would be somewhat faster.<p>This article is basically trolling java, and it seems a number of people have taken the bait. Different languages have different strengths and weaknesses. You'll choose the one most appropriate to the task required. If that's printing "Hello World" to the console then fine, but I doubt many people would think "java" when presented with this requirement.
onedognight将近 14 年前
The solution to java's slow startup time is gcj. Once compiled with gcc's java compiler, a java hello world will have C like startup times.<p><pre><code> echo 'class Hello {public static void main(String[] args) {System.out.println("hello, world");}}' &#62; Hello.java gcj --main=Hello -o Hello Hello.java time ./Hello echo 'main() { printf("hello world\n");}' | gcc -x c -o hello - time ./hello</code></pre>
评论 #2699178 未加载
dexen将近 14 年前
With disk caches primed, the main culprit may be the dynamic linker. Some of those environments (Java, Perl, Python, PHP that others mention in this thread) always load substantial number of dynamic libraries before doing anything useful. That doesn't come free. Numberous symbols have to be resolved, some static data initialized. There's non-trivial VirtualMemory to set up for such libraries, too.<p>For some more info: <a href="http://harmful.cat-v.org/software/dynamic-linking/" rel="nofollow">http://harmful.cat-v.org/software/dynamic-linking/</a><p>EDIT: a micro-benchmark between static and dynamic C program:<p><pre><code> gcc -- static a.c time (for i in `seq 1024`; do ./a.out &#62; /dev/null; done; ) real 0m0.958s #### gcc a.c # that's dynamic linking time (for i in `seq 1024`; do ./a.out &#62; /dev/null; done; ) real 0m1.292s </code></pre> ...and that's just libc alone! Those times were quite stable across several runs, so it's not some random one-time fluctuation.<p>The code:<p><pre><code> #include &#60;stdio.h&#62; int main(void) { puts("hello world!"); return 0; }</code></pre>
评论 #2701716 未加载
评论 #2699527 未加载
TheFacelessMan将近 14 年前
Ignorance and stupidity is running amok. This kind of trivial benchmark is not only incredibly dumb but is ACTIVELY HARMFUL to the programming community. Consider the conclusion drawn by author a few posts down in the thread<p>"Astonishing indeed. The whole thing confirmed my hunch that Bash, Chicken, and C provide a complete toolset to tackle 99.9% of programming needs."<p>No no no! Try running anything non-trival in bash or python and compare that to the java. Obviously if all you ever want to do with programming is write little boring scripts then you shouldn't be using a language like java in the first place. For anything mildly interesting and performance intensive Java is pretty much a no brainer only behind c/c++ amongst the major languages. For a site with REAL benchmarks which actually mean anything unlike the language fanboyism in this posted article checkout <a href="http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php" rel="nofollow">http://shootout.alioth.debian.org/u64q/which-programming-lan...</a>
评论 #2701676 未加载
评论 #2700306 未加载
abecedarius将近 14 年前
Just tried LuaJIT on a MacBook:<p><pre><code> 4 ms: C, gcc (median real time) 4 ms: bash 5 ms: LuaJIT 2.0.0-beta4 73 ms: Python2.6.1 </code></pre> So Bash still wins! I wonder if it gets any special advantage from getting invoked from itself.
afiler将近 14 年前
To my great astonishment, Ruby's performance was much closer to bash than Python in my own test: 0.572sec for 101 runs in Ruby, versus 4.276sec with Python and 0.318sec with bash. I now feel slightly less bad for all those shell scripts I've written in Ruby instead of bash.
评论 #2699944 未加载
glenjamin将近 14 年前
Is this level of micro-benchmarking actually useful for the given use-case?<p>When "writing shell scripts / cron jobs / random commandline utilities" I believe my priorities are<p>1) Does it work? 2) How easy is this to write? 3) How easy is this to read?<p>In that order.
评论 #2699209 未加载
评论 #2700579 未加载
melling将近 14 年前
Someone want to do a test for Scala? Why can't I have it all?
ashishb4u将近 14 年前
when will people stop comparing languages based on their runtime speeds?
评论 #2698893 未加载
评论 #2698907 未加载
评论 #2699004 未加载
gubatron将近 14 年前
that has got to be the most useful language benchmark of all times... for those that don't go past the "Hello World" step that is.
dkd903将近 14 年前
What about PHP? Will it have same results as C?
评论 #2698805 未加载
评论 #2698808 未加载