lalitmaganti

5 ms·

1.
by lalitmaganti 21d ago
Because that would also cause the dependencies to be compiled in series also! The point was only to measure "what if the Bun crate was built in one shot" not any dependencies of Bun.
2.
by lalitmaganti 23d ago
They did not, I did cc Jarred on X but not reached out anything beyond that!
3.
by lalitmaganti 23d ago
There's an open bug for adding macOS support to buildprof: https://github.com/LalitMaganti/buildprof/issues/2 If you mean "how would I implement it without ptrace", there are a few options but
4.
by lalitmaganti 24d ago
Yes the whole article is about exactly that :) You can also use --compiler-traces to understand the inside of the linking process as well; these annotations are provided by lld.
5.
by lalitmaganti 24d ago
> A) Is there any performance penalty on the compiled result due to being optimized in separate pieces AFAIK, the answer to this is no but only if LTO is doing a good job and actually optimizing well across object files. > B) If not
6.
by lalitmaganti 24d ago
Diffing is something I definitely want to support. I've filed https://github.com/LalitMaganti/buildprof/issues/12 to add support for this, I have ideas!
7.
by lalitmaganti 24d ago
> The bun team tried to parallelize Zig's semantic analysis a while back - and it DID compile about 4x as fast... I actually collected a build with multi-threading turned on [1]. It helped quite a bit, cutting the Zig object time fr
8.
by lalitmaganti 24d ago
Nice idea! I was only thinking about "how could I make Zig more efficient", I didn't even consider making Rust more similar to Zig. I added a Python script wrapping rustc which serializes all rustc invocations for bun_* crate
9.
by lalitmaganti 24d ago
Having spent ~3 weeks of evenings and weekends on this, I was a bit burned out to keep trying to optimize especially because all of this code is just a dead end anyway... The fix seemed to be to split up Bun's Zig module into ~100 piec
10.
by lalitmaganti 24d ago
It's actually trivially easy to add a "automated report" feature to buildprof due to its architecture (just a few SQL queries on top of Perfetto's trace processor). And I'm sure AI could hill climb the build time ba
11.
I made a build visualizer to understand Bun's compile times(lalitm.com)
171 points by lalitmaganti 24d ago|32 comments
12.
Review a pull request by booting it(fzakaria.com)
4 points by lalitmaganti 26d ago|0 comments
13.
by lalitmaganti 1mo ago
I suggest also reading Kevin Buzzard's blog post which was just posted: https://xenaproject.wordpress.com/2026/09/04/flt-anthropic-h... Provides great context on this accomplishment, what it means but al
14.
by lalitmaganti 1mo ago
(author here) I really like your framing here! I think it captures the essence of my thinking in a really concise and coherent way.
15.
by lalitmaganti 1mo ago
Thanks for letting me know; I cannot reproduce this myself on my mobile (it should be white text on a dark grey background) but I pushed a speculative fix which might improve things. Please let me know if it helps or, if not, I would love
16.
Reverse-engineering Find My People to stalk a friend, cause I can(zerotistic.blog)
2 points by lalitmaganti 2mo ago|0 comments
17.
Opus 5 doesn't use em-dashes in code comments(lalitm.com)
1 points by lalitmaganti 2mo ago|0 comments
18.
by lalitmaganti 2mo ago
It absolutely can be done [1] but it is a lot of effort to do high quality error recovery. It's easier in languages with natural "synchronization points" [2], harder in languages which don't have them. Having built a
19.
Responsibility Is Taken Before It Is Given(lalitm.com)
5 points by lalitmaganti 2mo ago|0 comments
20.
Changing Devtools Is Cheap. Owning Them Isn't(lalitm.com)
2 points by lalitmaganti 2mo ago|0 comments
21.
by lalitmaganti 2mo ago
This is basically similar to what bb ( https://getbb.app/ ) is also doing. It's interesting to see many different people exploring things in this space...
22.
How I Find Problems to Solve as a Staff Engineer(lalitm.com)
2 points by lalitmaganti 2mo ago|1 comments
23.
by lalitmaganti 2mo ago
> So I don't think advanced AI that can help debug and maintain software will stay out of the reach of most people for very long. But then what stops the upstream tools from doing exactly the same thing and getting the same speedu
24.
by lalitmaganti 2mo ago
As a maintainer of a devtool which has strived to make itself easily forkable and modifiable, I can see the allure of this line of thinking but I think it's sadly too idealistic. Engineers using devtools are not so different to an aver
25.
Giving and taking credit in big tech companies(seangoedecke.com)
6 points by lalitmaganti 2mo ago|1 comments
26.
GitHub has alternatives, but no replacement(lalitm.com)
87 points by lalitmaganti 2mo ago|134 comments
27.
by lalitmaganti 2mo ago
Have to plug the original Swiss Table talk by Matt Kulukundis: https://youtu.be/ncHmEUmJZf4?si=YRl2pDvdGZgd2ROq Excellent talk which explains the concepts really clearly and concisely.
28.
by lalitmaganti 3mo ago
I agree with the actual principle I think this article is trying to put across (don't give up on technical quality too early by dismissing it as "perfection") but I strongly disagree with the framing. My biggest problem comes
29.
Static search trees: 40x faster than binary search (2024)(curiouscoding.nl)
199 points by lalitmaganti 3mo ago|15 comments
30.
When Impressive Performance Gains Do Not Matter(blog.colinbreck.com)
5 points by lalitmaganti 3mo ago|0 comments

More ›