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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Compile times, and why “the obvious” might not be so

4 点作者 parsecs大约 4 年前

1 comment

ggm大约 4 年前
Love this blog, love this article. The &quot;has GC&quot; thing and &quot;is a VM&quot; thing goes pretty quickly to &quot;you used a REPL didn&#x27;t you?&quot;<p>To compile times.<p>A lot of code I use is .&#x2F;configure. the autoconf&#x2F;autogen thing looks to me to be doing shell wrapper around basic CPP&#x2F;CC&#x2F;AS&#x2F;LD operations (well, actually the ${CC} called to do the phases mostly) and I <i>think</i> this gets me .o and related files with timestamps I can trust, but past experience was, it was inherently unsafe to modify a .h and then expect the dependency chain to be correct.<p>So. I got into the habit of destroying the intermediate products to be sure to be sure the dependency chains remade everything they needed.<p>I think this kind of thing blows out costs.<p>Also, there are the kind make scenarios where &quot;make all&quot; does stuff, but make install actually does MORE and I hate those. The delayed cost of making things &quot;for real&quot; is high, for the thing which I thought I had already done.<p>My own code had&#x2F;has really tiny structure. I think if i had coded enough to need richness in library and modules I&#x27;d be more conscious of the maintenance side of this, and of the burden to make Makefiles which did the right thing, with dependencies.<p>I remember older compilers (OSF&#x2F;1?) which demanded you make it, run it for 30 sec, then let the compiler use the runtime to decide which optimisations to re-apply making it for real.