Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finding and fixing Ghostty's largest memory leak

mitchellh.com

Post reply on HN
Print view View original

121–130 of 152 posts

Re: Finding and fixing Ghostty's largest memory leak

#121

Post by dkdcio »

cbmuser wrote: post #94
yoyohello13 wrote: post #56

Earlier quoted context omitted.

A lot of developers use the terminal as their primary interaction with the computer. Nvim, tmux, etc. Having it be fast is an extreme quality of life improvement. For devs who only ever use the terminal integrated into their ide then it’s probably less important.

Can you elaborate on that a bit, please? I have never found myself in the situation where my terminal emulator would be too slow and I‘m using it for the majority of my day-to-day work. I honestly never ran into a situation where I would habe blamed the terminal emulator for being too slow.

not the same person but in the flow of doing things those little pauses (tens of milliseconds) do matter. I open/close nvim (and less-so tmux) a ton, and run lots of commands per day. I don’t want to wait

and once you get used to things being that fast, it’s hard to go back (analogous to what people say about high-refresh screens/monitors)

all that said the speed of the default mac terminal (and other emulators I tried) was always fine for me, performance was not why I switched to Ghostty

Re: Finding and fixing Ghostty's largest memory leak

#122

Post by vlovich123 »

uecker wrote: post #96
vlovich123 wrote: post #92

Earlier quoted context omitted.

Please don’t get defensive and spread silly FUD. You can be proud of what you’ve accomplished without feeling sad that a different language has strengths that yours doesn’t. Calling unsafe mmap APIs not only is unlikely to run into the corner cases where unsafe Rust is tricky to get right, there’s “millions” of crates that offer safe APIs to do so and it’s fundamentally not hard to write it safely (it would be very h…

I don't think this is silly FUD. The article describes a scenario where the low-level abstractions itself was buggy in a subtle way, the comparison to "unsafe" Rust seems entirely fair to me. (edited for typos)

The low level abstraction was buggy because they forgot to free memory because they confused types, not because of mmap.

Thats completely orthogonal to the question and less likely in Rust because you would generally use an enum with Drop implemented for the interior of the variants to guarantee correct release.

And mmap is no more difficult to call in Rust nor more magically unsafe - that’s the FUD. The vast majority of Ghostty wouldn’t even need unsafe meaning the vast majority of code gets optimized more due to no aliasing being automatic everywhere and why the argument that “zig is safer than unsafe rust” is disingenuous about performance or safety of the overall program.

Re: Finding and fixing Ghostty's largest memory leak

#123

Post by vlovich123 »

tialaramex wrote: post #107
uecker wrote: post #96

Earlier quoted context omitted.

I don't think this is silly FUD. The article describes a scenario where the low-level abstractions itself was buggy in a subtle way, the comparison to "unsafe" Rust seems entirely fair to me. (edited for typos)

With Rust you always could unsafely do whatever went wrong in somebody's C or Zig or whatever, but the question is whether you would. Rust's technical design reinforces a culture where the answer is usually "No". I don't find the claim that weird low level mmap tricks here are perf critical at all persuasive. The page recycling makes sense - I can see why that's helping performance, but the bare metal mmap calls smel…

I think we can agree that Mitchell knows what he’s doing and isn’t playing around with mmap just because. It’s probably quite important to ensure a low memory footprint. But mmap in rust is not extra risky in some weird mystical way. It’s just a normal FFI function to get a pointer back and you can trivially build safe abstractions around it to ensure the lifetime of a slice doesn’t exceed the lifetime of the underlying map. It’s rust 101 and there’s nothing weird here that can cause the unsafe bits here to be extra dangerous (in general unsafe rust can be difficult to get right with certain constructs, but it doesn’t apply here).

Re: Finding and fixing Ghostty's largest memory leak

#124

Post by vlovich123 »

uecker wrote: post #108
tialaramex wrote: post #107

Earlier quoted context omitted.

With Rust you always could unsafely do whatever went wrong in somebody's C or Zig or whatever, but the question is whether you would. Rust's technical design reinforces a culture where the answer is usually "No". I don't find the claim that weird low level mmap tricks here are perf critical at all persuasive. The page recycling makes sense - I can see why that's helping performance, but the bare metal mmap calls smel…

Also in C or Zig you do not need to create your own memory management using mmap. Whether this is necessary in this case or not is a different question. In the end, if the Rust advantage is that "Rust's technical design reinforces a culture" where one tries to avoid this, then this is a rather weak argument. We will see how this turns out in the long run though.

The long run has already spoken. Go look at the reports out of Microsoft and Android. It’s screamingly clear that the philosophy of Rust that most code can be written in safe with small bits in unsafe is inherently safer. The defect rate plummets by one or two orders of magnitude if I recall correctly. C is an absolute failure (since it’s the baseline) and Zig has no similar adoption studies. You could argue it will be similar if you always compile releasesafe, but then performance will be worse than C or Rust due to all the checks and it’s unclear how big a while the places that aren’t dynamically checked are.

Oh and of course rust is inherently slightly faster because no reference aliasing is allowed and automatically annotated everywhere which allows for significant aggressive compiler optimizations that neither C nor Zig can do automatically and is risky to do by hand.

Re: Finding and fixing Ghostty's largest memory leak

#125

Post by ATMLOTTOBEER »

fragmede wrote: post #41
mitchellh wrote: post #6

Earlier quoted context omitted.

> Probably not a huge deal, but it does seem the fix will needlessly delete and recreate non-standard pages in the case where the new page needs to be non-standard, and the oldest one (that needs to be pruned) already is non-standard and could be reused. This is addressed in the blog post. It is how the PageList has always worked, and also how it worked before with the bug, because during capacity adjustment we would…

Of all the things to be impressed by you about, your patience is commendable. I'd be losing my shit if someone couldn't be bothered to read what I wrote and just spout off about something I'd addressed in my writing, but I suppose that's why your bank account has two commas and a bunch more. Thank you for everything. Can we go flying sometime?

[flagged]

Re: Finding and fixing Ghostty's largest memory leak

#126

Post by surajrmal »

KaoruAoiShiho wrote: post #71

What's the best claude code terminal? I'm not sure if ghostty is it, which one can sync to iphone / android tablet for remote use of the same session?

Sharing a session is independent of the terminal emulator itself. Use tmux for that. There are a handful of good terminal emulators. Weztern, alacritty, and kitty are popular. I use. Tiling window manager so I prefer to avoid tabs and use alacritty for that reason.

Re: Finding and fixing Ghostty's largest memory leak

#128

Post by fartfeatures »

amazingman wrote: post #78
DrammBA wrote: post #67

Earlier quoted context omitted.

Are the nightly releases the expected way to get timely bugfixes?

That is how software releases generally work. AFAICT this is not a bug with broad impact or security implications.

I guess thats arguable, a memory leak can make a system unpleasant to use although I accept it can be solved by repeatedly restarting the offending app.

Re: Finding and fixing Ghostty's largest memory leak

#129

Post by fragmede »

ATMLOTTOBEER wrote: post #125
fragmede wrote: post #41

Earlier quoted context omitted.

Of all the things to be impressed by you about, your patience is commendable. I'd be losing my shit if someone couldn't be bothered to read what I wrote and just spout off about something I'd addressed in my writing, but I suppose that's why your bank account has two commas and a bunch more. Thank you for everything. Can we go flying sometime?

[flagged]

Hell yeah! You don't got any heros? No body you look up to or respect? Not even a little bit?

Re: Finding and fixing Ghostty's largest memory leak

#130

Post by Aurornis »

fragmede wrote: post #41
mitchellh wrote: post #6

Earlier quoted context omitted.

> Probably not a huge deal, but it does seem the fix will needlessly delete and recreate non-standard pages in the case where the new page needs to be non-standard, and the oldest one (that needs to be pruned) already is non-standard and could be reused. This is addressed in the blog post. It is how the PageList has always worked, and also how it worked before with the bug, because during capacity adjustment we would…

Of all the things to be impressed by you about, your patience is commendable. I'd be losing my shit if someone couldn't be bothered to read what I wrote and just spout off about something I'd addressed in my writing, but I suppose that's why your bank account has two commas and a bunch more. Thank you for everything. Can we go flying sometime?

> I'd be losing my shit if someone couldn't be bothered to read what I wrote and just spout off about something I'd addressed in my writing

In my experience that’s a universal feature of comment sections everywhere, and HN is not an exception. This is very common in HN comments which is why it’s important to always read the article, not just the comments.

Post reply on HN