Lalit Maganti

RSS: https://lalitm.com/index.xml
Lalit Maganti 的个人博客与项目主页,记录个人文章、项目与思考。

我做了一个构建分析器,来搞清Bun的编译时间为什么差5倍

Lalit Maganti开发了buildprof,一个开源的构建追踪工具,用于可视化Linux下软件编译的时间分布。他用它分析了Bun从Zig切换到Rust后编译提速5倍的真相:全链路LTO和单模块结构是最大瓶颈,改用ThinLTO并将WebKit也重建后,Zig构建从24分钟降到15分钟,但根本差距在于Rust拆成了90多个crate而Zig是一个单模块无法并行编译。
评论点赞收藏17 天前

Perfetto 渲染算法改进:让 PyTorch 性能分析图更清晰

Perfetto 改进了 PyTorch 性能分析数据的渲染算法,让时间线追踪图更紧凑可读。PyTorch profiler 发出的事件在 Chrome Trace Event 规范中属于非法重叠,Perfetto 之前会丢弃这些事件,后来改为合并显示但无法还原嵌套关系,导致渲染结果混乱。 新算法将排序方式从按起始时间改为按高度降序,深调用栈优先占据低行,宽而浅的事件则放在旁边,同一份追踪数据现在显示更紧凑。
评论点赞收藏44 天前

责任是在被赋予之前先被承担

<p>要在大型科技公司晋升为软件工程师,通常需要表现出对某个产品或领域的“所有权”。这意味着要对此负责,并决定未来应该发生什么。</p><p>我经常听到一些初级工程师问:“当我的经理没有给我任何东西时,我怎么能证明所有权?”这种思维方式是陷阱:很容易陷入,但终究是陷阱。</p><p>问题在于他们把责任当作一个完整、自成一体的机会,必须有人先给他们。根据我的经验,他们把它弄错了:<strong>责任在正式授予之前就已被展示。</strong></p><p>设身处地为你的技术负责人(TL)着想:通过“赋予”责任,他们实际上是在默许接受你决策的后果。他们不仅需要信任你完成工作,还需要在没有持续监督的情况下行使判断力。</p><p>他们问自己最重要的问题是:“这个人处理问题的方式和我一样吗,<strong>或者更好</strong>?”如果答案是肯定的,他们可以把更多责任交给你。</p><h2>我如何成为一名所有者 </h2><p>当我开始创作时我主要在我的组长指导下构建了它的痕迹分析工具。当我开始自己做实施决策时,他经常发现我忽略的重大问题。</p><p>例如,我为三四个我认为无关的数据结构分别构建了类别。我的组长坚持说它们都是桌子,尽管我看不出怎么统一它们。如今,Perfetto的跟踪处理器拥有100多个表,均通过声明式定义并由该共同抽象生成。</p><p>我总是试图理解他的思考过程:他怎么会想到我错过的东西?他用了什么方法才走到这一步?</p><p>随着时间推移,我自己也采纳了他的方法,用来对API变更或性能改进进行压力测试,然后再提出建议。我更多的想法开始收到简单的“好,尽管…</p>
评论点赞收藏45 天前

改工具便宜,拥有工具不便宜

<p>在 (David Crawshaw 认为,由于编码代理的出现,我们现在处于一个开发工具将由个人用户个性化的时代。具体来说,代理能够跳转到新的代码库,构建任何我们想要的东西,这意味着我们将在日常使用的开发工具源代码(即使是没有扩展 API 的)上进行黑客攻击,添加功能并自动在不同版本间重新基于补丁。</p><p>这个论点很有吸引力,尤其是对那些自认为是制造者或修补匠的读者来说:毕竟,你可以对所用的一切进行超调谐的想法听起来像是乌托邦;这意味着事情可以正常运作<em>没错</em>你想怎么做。</p><p>但我认为克劳肖在写作时低估了持续的代价</p><blockquote>“无论是前期固定成本还是个性化软件的持续成本都消失了。”</blockquote><p>虽然人工智能已经承担了前期成本<em>变化</em>软件要低得多,但真正个性化的软件仍然需要你的注意力。而在人工智能时代,关注度比以往任何时候都更稀缺。</p><p>我已经维护了一个开源开发工具,设计用来修改和分支已经有九年了我可以说大多数用户都不喜欢<em>想要</em>用来定制开发者工具。他们希望有人让工具可靠且连贯,这样他们就能专注于他们开启时要解决的问题。<br><br>他们只有在变更对工作流程至关重要且其他途径无效时才会选择源代码修改。</p><p>这并不是说这种个性化不会变得更普遍:我绝对认为会。我只是认为它会以强有力的核心体系形式出现,边界和延伸点明确。</p><h2>个性化依然需要一个人 </h2><p>作为一个思想实验,想象一个没有扩展API的开源微分查看器。你觉得大多数差异音都很吵,所…</p>
评论点赞收藏51 天前

GitHub有替代品,但没有替代品

Codeberg禁止主要AI生成代码的项目托管,引发开源社区对GitHub替代方案的讨论。作者认为GitHub真正的护城河不是代码托管功能,而是它建立的共享社交层——用户身份、贡献惯例和项目发现机制。 自托管Git服务对个人项目可行,但陌生人贡献需要降低门槛,而目前没有任何替代平台能在同等规模上复制这种社交基础设施。
评论点赞收藏59 天前

AI 代理不是子系统维护者

<p>Redis 的创始人 Antirez 最近主张,使用人工智能的专业程序员应将自己看作.</p><p>他比喻的关键部分是:</p><blockquote>自动编程则由技术专家、程序员、设计师、软件架构师等专家扮演 Linus 的角色,代理和大型语言模型则扮演不同子系统的维护者角色。</blockquote><p>这个比喻对我来说不适用。以现有的LLM为例,我不能成为Linus,LLM也不能成为我的子系统维护者。</p><p>为什么?一句话:<em>信任</em>.林纳斯信任他的子系统维护者。他能够专注于大局,安心相信他的副官们会在长期维护子系统时始终保持良好判断。<br><br>他知道这一点,因为他们通过证明自己赢得了他的信任<em>一遍又一遍</em>.</p><p>每次我试图给现有的LLM机会以这种方式证明自己,结果都后悔了。从总体来说,我就是不喜欢他们做出的许多决定。即使在性能、数据库、开发者工具的用户体验等领域,我也曾有资格评判AI表现如何。<br><br>我对此有深入的写作除此之外,我在工作和其他副业项目中都以多种方式使用了LLM。</p><p>如果有人反复这样做,我不会把我拥有的项目的任何部分都交给他。信任必须靠自己赢得,而现在的经纪人还远远没有赢得足够的信任让我退一步。<br><br>在设计成型期间我参与,比最后发现一系列合理的地方决策最终导致错误系统要便宜得多。</p><p>而且,不,仅仅通过测试或静态验证对我来说是不够的。我最常不喜欢的决定,恰恰是那些难以轻易制止的。检测无法告诉我......</p>
评论点赞收藏65 天前

我是如何作为 Staff 工程师发现待解决问题的

Lalit Maganti 分享了他作为 Staff Engineer 如何发现值得解决的问题。他反对“战略性思考”,主张像海绵一样吸收日常噪音,通过倾听团队成员的抱怨和痛点来识别真正阻碍效率的问题。 这种方法强调自下而上的主动性,而非等待管理层分配任务。文章指出,虽然解决指派难题能带来晋升,但发现并解决领导者尚未意识到的重要问题,往往能产生更深远的影响。 不过,这种方法主要适用于基础设施和开发者工具团队,且需要一定的自主权环境。
评论点赞收藏66 天前

坚持 blogging 一年后,我决定做出的改变

<p>对于我而言,写作与世界之间的互动始终是随着时间推移而起伏变化的。<br>从小时候起,我就一直喜欢分享自己的想法——从网站开始,一路延续至今。<br>在那些坚持写作的日子里,我曾尝试过各种类似“博客”的形式来记录技术项目,而这些内容往往也会延伸到分享个人信念。</p><p>距离我最近一次尝试、并自认为将是一生致力于的事业,已经过去一年了。<br>因此,我一直在反思这段旅程的进展,并由此做出了若干决定,规划未来如何重新调整和优化我的创作方向。</p><p>提升文章的重要性</p><p>在我的写作中,我有两个目标:</p><p>我希望拥有自由,可以随心所欲地书写自己想写的内容,并根据自己的意愿投入或减少精力。</p><p>我非常重视以最恰当的方式呈现自己认为优秀的作品,让读者能够以最佳的体验方式阅读到这些内容。</p><p>尽管乍一看似乎彼此矛盾,但这两个目标其实存在一定的冲突。<br>有时我会撰写一些“TIL”或低耗能的帖子,这些内容对大多数人来说可能并不那么有趣;<br>而我也不希望把这些内容与我初次与读者见面时所呈现的、最为出色的作品混为一谈。</p><p>事实上,这种困境并非我独有——许多网络作家都面临着同样的难题,而且他们也采取了不同的应对策略。我曾考虑过两种方案:</p><p>在博客上发布高耗能的内容,在社交媒体上则侧重低耗能的内容。</p><p>将博客上的内容分为高耗能(文章、散文)和低耗能(笔记、片段、TIL等)两类。</p><p>我不太喜欢方案一,因为我其实并不太喜欢社交媒体。<br>多年来我完全远离社交媒体,如今又不得不勉强回归,因为社交媒体确实有助于…</p>
评论点赞收藏75 天前

Git 的 history 命令值得更多关注

Git 2.54/2.55 引入的 experimental history 子命令(fixup/reword/split)提供了类似 jj 的原子化历史重写能力,自动处理分支重基且不留半破坏状态。 作者通过对比 jj 指出其局限(如暂不支持合并提交),但强调无需切换工作流即可在 Git 中获得核心便利。
评论点赞收藏78 天前

Perfetto v57:修复 PyTorch 追踪问题,新增 journald 日志与 AI 技能

Perfetto v57 解决了 PyTorch Profiler 生成的追踪数据在单轨道重叠事件无法显示的关键 Bug。作者深入分析了 Chrome Trace Event 规范中 Duration 事件与 Async 事件的冲突,以及上游渲染器的缺陷。 对于使用 PyTorch 进行性能分析的开发者和工程师,此更新能显著改善可视化体验。同时新增了对 journald 日志的支持及 AI 辅助技能。
评论点赞收藏89 天前

当显著的性能提升毫无意义时

性能优化常陷入局部瓶颈误区。分布式系统与客户端开发均存在非线性收益,CPU Profiling 显示的热点未必是最终瓶颈。需全局审视系统链路,避免在边际增益处过度投入。
评论点赞收藏91 天前

Syntaqlite 0.6: SQLite dot commands and pyodide

Since my original launch post for syntaqlite, I’ve been quietly working away on it in the background. A lot of the work has been fixing correctness bugs which I discovered as I integrated it into prod...
评论点赞收藏103 天前

Don't answer the first question

In my work on Perfetto, a performance debugging tool, one question I get often is: “how do I split a Perfetto trace into multiple files?” Instead of answering directly, I say: “there isn’t an easy way...
评论点赞收藏135 天前

Which country voted the best at Eurovision?

Eurovision was on yesterday. I’ve never been interested much in the musical side but the weird political dynamics of Eurovision voting have always fascinated me; I tune in each year just for them and ...
评论点赞收藏135 天前

Number in man page titles e.g. sleep(3)

If you do Linux systems programming, you will have likely pored over man pages, either on the command line or, my personal preference, using the excellent or. I’ve always seen the numbers in sleep(3) ...
评论点赞收藏177 天前

Why senior engineers let bad projects fail

When I was a junior engineer, my manager would occasionally confide his frustrations to me in our weekly 1:1s. He would point out a project another team was working on and say, “I don’t believe that p...
评论点赞收藏257 天前

登录芦苇

登录后关注作者、收藏内容和参与讨论。