编程与软件工程hillelwayne.com编辑精选
性能很重要
Performance Matters
2019 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
文章以急救人员使用的电子病历（ePCR）等场景为例：软件功能更全，却因响应迟缓、交互卡顿而被一线人员弃用，转而用纸笔记录。作者由此论证性能不是可选的优化项，而是可用性、工作流甚至安全的一部分。
为什么经久不衰：它用具体的一线场景说明延迟如何摧毁工具采用率，提醒开发者性能本身就是用户体验和正确性的一部分。
HN 评论精选
一线急救人员证实 ePCR 体验差，但采用纸笔还涉及手套、流程等整体可用性问题，不只是延迟。
不确定作者所在地区，但据我所知已经没哪个州还允许纸质 PCR，电子 PCR 是常态。可我基本到医院前都不打开笔记本：不是单纯因为卡顿，而是整套设备和 UI 太麻烦——用纸笔不用反复脱戴手套，也能用速记快速记录；多数急救人员都是先在纸上记，进急诊等床位时再录入。
JshWright查看英文原文
Not sure where the author is from, but I'm not aware of any states that still allow paper PCRs. ePCRs are just a fact of life. I pretty much never bother opening the laptop until I'm at the hospital. There are a lot of reasons for that, but a laggy UX isn't really one of them (despite the fact that the UX is indeed super laggy on any ePCR I've ever used). Instead I use a pen and paper (or a pen and a strip of white medical tape on my thigh, for a more critical patient). The reason I don't bother is because the whole UI is just too much of a hassle. Not the application frontend, the whole thing. The laptop, the keyboard, etc. With a pen and paper I don't have to keep taking my gloves off and putting new ones on each time I need to switch from documenting something to caring for the patient (a pen is trivial to wipe down, or just toss if needed). With a pen and paper I can jot simple notes in a shorthand I'm familiar with, rather than having to navigate to the right page to enter the information I want to record at the moment. I know very few providers that bother touching the laptop prior to arrival at the hospital. Generally we write notes on paper, then bring the laptop into the ER and start typing while we we're waiting for a bed for our patient (it's not uncommon that this takes long enough to get the whole chart written). At my agency we have two hours from when we transfer care to when the chart has to be signed off and locked. I also chuckled at the suggestion that "0.1% of PCRs have errors that waste an hour of a doctor's time". In my experience 0.1% is pretty much how frequently the PCR gets reviewed at all in the ER, and anything important enough to spend an _hour_ on would have been mentioned up front during the transfer of care (nevermind the fact that an hour is an absurd amount of time for a doctor to be spending on a single patient).
医疗设备经验表明延迟有硬性上限，进度指示只能缓解挫败感，慢 UI 控件尤其不可接受。
90 年代写医疗设备软件时，我们对认知漂移有明确策略，包括性能上限、beta 测试中的漂移测试等。测试中，外科医生最多只能“空闲”10 秒还能保持任务状态。我们还发现，加入 spinner、进度条等不一定减少认知漂移，但能减少情绪挫败。最糟的是 UI 元素变慢：按钮反应慢、滚动卡顿、下拉菜单拉不下来。正如作者所说，这类延迟几乎不可容忍。
Ensorceled查看英文原文
When I was writing software for medical devices in the '90s, we had a very clear policies for dealing with cognitive drift that included performance ceilings, testing for drift in beta testing, etc. In our testing, 10 seconds was the absolute maximum time that a surgeon could "idle" and stay on task in surgery. In addition, we found that including spinners, progress bars, etc. would not necessarily reduce the cognitive drift but would reduce emotional frustration. The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. I presume that, like website response rate tolerance thresholds that have dropped from 5 seconds to less than 2 seconds now, the medical industry is probably using much lower times now.
Knuth 的原话并非叫人不顾性能，而是反对在非关键处盲目优化，同时别放过关键 3%。
引用“过早优化是万恶之源”的人从不给全句。全句有重要 nuance：“程序员浪费大量时间思考或担心程序中非关键部分的速度，考虑到调试和维护，这些努力实际有很强负面影响。我们应忘记小效率，约 97% 的情况：过早优化是万恶之源。但我们不应放过那关键 3% 的机会。”没有上下文，这句话不完整，人们不幸把它理解为“永远不用关心代码效率”，这完全不是 Knuth 的本意。
Gene_Parmesan查看英文原文
People who quote "premature optimization is etc." never provide the full quote. The full quote has a significant degree of highly important nuance. > "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." "Premature optimization is the root of all evil" is incomplete without the surrounding context, and people unfortunately take it to mean "never worry about how efficient your code is," which is not at all what Knuth intended.
响应迟缓的 UI 就是严重缺陷；UI 应按软实时系统对待，医疗数据出错也可能致命。
小小挑刺：文中说 ePCR 唯一问题是太慢，但那就是严重 bug。UI 是软实时系统，它没能满足截止时间到用户认为不可用的程度。自动驾驶系统不是最终做出正确决定就行，而必须在截止时间前做出；否则按定义就是 bug。文章说这不是关键软件、坏了不会有人突然死掉——真的吗？如果软件破坏患者数据，可能有人会死。
MaxBarraclough查看英文原文
A slight nitpick: > The ambulance I shadowed had an ePCR. Nobody used it. I talked to the EMTs about this, and they said nobody they knew used it either. Lack of training? No, we all got trained. Crippling bugs? No, it worked fine. Paper was good enough? No, the ePCR was much better than paper PCRs in almost every way. It just had one problem: it was too slow. That is a crippling bug. The UI is a soft real-time system, [0] and it's doing such a poor job of meeting its deadlines that the user considers the system to be unusable. If you're writing an autopilot system, it's not enough for the system to eventually make the right decision, it must arrive at the right decision before the deadline. Failure to do so would by definition qualify as a bug. > Most of us aren’t writing critical software. But this isn’t critical software, either: nobody will suddenly die if it breaks. Won't they? If the software corrupts the patient data, someone could die, right? Elsewhere the article essentially says as much: > An error might waste valuable time as nurses chase invisible problems or ignore obvious ones. Worst case, it leads to the wrong treatment. In emergency situations these mistakes can be fatal. [0] https://en.wikipedia.org/wiki/Real-time_computing#Soft edit I see brundolf's comment already makes some of these points
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选