主题: performance
-
生产环境中的持续性能剖析:常开的采样剖析能回答什么问题
持续性能剖析(continuous profiling)会系统性地随时间采集 CPU 和内存剖析数据,并以带标签的序列形式存储,这样团队就能查询昨天整个集群中哪个函数消耗的 CPU 最多、或两个版本之间发生了什么变化之类的问题;采样式剖析器的开销足够低,可以一直保持开启,而 Go 的 /debug/pprof/ 之类的运行时端点或 eBPF 代理则负责提供这些剖析数据。
-
Summarizing time in system calls with strace -c, its overhead, and perf trace as an alternative
strace -c counts time, calls and errors per system call instead of printing every call, but strace's own manual warns that a traced process runs more slowly than an untraced one; perf trace, described as a strace-inspired tool built on perf_events rather than ptrace, is the lower-ceremony alternative when that overhead matters.
-
变更基准测试:预热、重复次数、离散程度与应报告的内容
计时对比只有经得起噪声考验才算得上结果:固定工作负载、丢弃预热运行、将各变体的多次重复交替执行、在查看数据前先确定要用的统计量,并在每个数字旁报告离散程度与环境信息。小于运行间离散程度的差异算不上发现。
-
A first look at Solaris performance: prstat, vmstat, mpstat, iostat and zpool iostat
prstat -a/-Z, vmstat, mpstat, iostat -xnz and zpool iostat are five read-only commands that cover most first-look performance questions on Solaris 11.4, with zone-aware and disk-latency detail that the similarly-named Linux tools present differently.
-
使用 USE 方法查找性能瓶颈
对 CPU、内存、磁盘、网络、锁等每种资源,检查利用率、饱和度和错误。USE 方法是一份检查清单,能快速发现瓶颈,无需先在应用层凭直觉猜测。
-
响应压缩:在哪一层做,排除哪些内容
在代理或应用中压缩文本响应(HTML、JSON、Markdown),跳过已压缩和流式内容,确保不同编码下的 ETag 如实对应表示,并设置 Vary: Accept-Encoding。
-
How much of an agent's context is tool output in real runs, and does trimming it change task success?
Open question: the MCP specification says clients should validate tool results before passing them to the model but leaves the amount to the client; in recorded agent runs, what share of tokens is tool output rather than instructions or reasoning, and does truncating, summarising or filtering tool output change task success, cost and latency?
-
使用 srcset、sizes 和 picture 实现响应式图片
带宽度描述符的 srcset 配合 sizes 属性,可以让浏览器根据当前视口和像素密度,选择能填满显示区域的最小图片文件。x 描述符为固定显示尺寸提供多种密度;带 source 元素的 picture 用于构图调整和格式回退。始终保留 width 和 height,避免图片加载时布局偏移。
-
Sampling Windows Server performance counters with Get-Counter and exporting them to CSV
Get-Counter samples named counter paths at a chosen interval, continuously or for a fixed count; Export-Counter (Windows PowerShell 5.1 only) preserves every field in the native BLG format, and relog converts a capture to CSV afterwards even without the original Export-Counter command.
-
生成、评议、修订:自我验证循环何时值得投入
当评议有外部信号(测试、验证器或来源)和固定评价标准时,让模型评议并修订自身输出的循环能改善结果;缺少这种依据时,已发表的研究结果表明它可能使答案变差。每轮至少增加两次调用,且两次调用的输入量都会随草稿增长。
-
VACUUM、autovacuum 与表膨胀
PostgreSQL 的 MVCC 在更新和删除后会留下失效的行版本;VACUUM 回收这些版本,维护统计信息,并防止事务 ID 回卷。应保持 autovacuum 启用,并针对繁忙表进行调优。
-
Web 字体加载:font-display、预加载、unicode-range 子集与度量匹配的后备字体
首次绘制就显示文字,并让品牌字体加载后不引发布局跳动:用 unicode-range 划分字体子集,只下载用到的文字系统;按角色选择 font-display(正文用 optional,标题用 swap);用 crossorigin 预加载首次绘制文件;声明带 size-adjust 及 ascent/descent 覆盖值的后备字体,使替换前后换行一致。
-
ES module builds with declared side effects shrink consumer bundles more than CommonJS builds
Hypothesis: for a library of many independent functions, a consumer that imports a few of them gets a smaller bundle when the library ships ES modules with a sideEffects declaration than when it ships CommonJS, because tree shaking depends on static import/export structure; a fixture-based comparison is proposed.
-
asyncio 何时有用,何时无益
asyncio 通过在 await 处挂起任务,在单个线程上运行大量受 I/O 限制的任务。它不会加速受 CPU 限制的代码,而协程中的阻塞调用会让整个事件循环停滞。
-
Web Vitals:LCP、INP 和 CLS 分别测量什么
Core Web Vitals 是三个真实用户指标:Largest Contentful Paint(最大可见元素的渲染时间,目标 2.5 秒)、Interaction to Next Paint(最长交互延迟,目标 200 毫秒)和 Cumulative Layout Shift(意外位移,目标 0.1)。每项都按页面加载的第 75 百分位评估。
-
When does client-side routing still pay off now that browsers offer bfcache, prerendering and cross-document view transitions?
Open question: in-page routers were adopted to avoid full page loads, at the cost of shell serving, 404 handling, scroll and focus restoration and a bundle that must arrive first; the back/forward cache, the Speculation Rules API and cross-document view transitions now address the original motivations in multi-page sites. For which sites and interaction patterns does an in-page router still measurably win?
-
使用 tracemalloc 快照查找内存泄漏
尽早通过 PYTHONTRACEMALLOC 或 tracemalloc.start(nframe) 开始跟踪,在预热后和 N 次迭代后各取一份快照,过滤导入噪声,再用 compare_to(..., 'lineno') 找出内存大小随 N 成比例增长的代码行;切换到 'traceback' 分组即可查看调用者。
-
Performance diagnosis from the macOS Terminal: top, vm_stat, memory_pressure, fs_usage, and powermetrics
macOS ships BSD-heritage and Apple-specific tools that overlap with what top/vmstat/iostat/strace do on Linux, under different names, units and privilege requirements: top -o cpu, vm_stat, memory_pressure, iostat, fs_usage, powermetrics, and sample <pid>.
-
Per-process CPU and I/O with pidstat and /proc/<pid>/io: finding what causes I/O wait
pidstat reports per-task CPU, memory and disk I/O without grepping a name out of top; reading /proc/<pid>/io directly separates logical I/O (rchar/wchar, including cache) from the physical read_bytes/write_bytes that actually reach the device.
-
为 Python 工作负载选择线程、进程或 asyncio
先判断热点路径的性质:等待 I/O 适合 asyncio(大量连接、异步库)或线程池(少量阻塞调用);纯 Python 的 CPU 工作需要进程或自由线程构建;释放 GIL 的原生代码可使用线程。限制每个池的规模,显式选择进程启动方式,并编写关闭流程。
机器可读: JSON