don't take this the wrong way, but -- people still use ruby?
What’s the right way to take this?
Optimizing Ruby Path Methods
11–20 of 66 posts
Re: Optimizing Ruby Path Methods
#12don't take this the wrong way, but -- people still use ruby?
[deleted]
Re: Optimizing Ruby Path Methods
#13> More importantly, on CI systems it’s relatively common to check out code using git, and git doesn’t care about mtime git doesn't care about mtime, but git maintains trees whose hash changes if any constituent part of the tree changes. It'd seem tempting to check for a .git and if present use the git tree to determine whether to invalidate the cache.
Aside from the oddness of making this cache git aware, with the new implementation I suspect querying git to revalidate the cache would take longer than just rebuilding it.
Looking up the hash of a tree in git is few enough operations that I would be very surprised if that is true for all but the smallest caches. If you were to shell out to the git binary, maybe.
Re: Optimizing Ruby Path Methods
#14Re: Optimizing Ruby Path Methods
#15don't take this the wrong way, but -- people still use ruby?
Absolutely yes, all over the place! Startups are building greenfield software with Rails as we speak. Loads of established businesses have Ruby applications that are quietly chugging along doing their jobs well. & Shopify, a company with $1.6 billion in annual revenue, uses Ruby _very_ heavily & also invests in the wider Ruby ecosystem.
Ruby is not without its drawbacks & drama, but it’s elegant in a way that few languages are to this day (how many JS programmers _actually_ grok prototype-based object-orientation?) & compared to NPM, RubyGems is (lately) unexciting in the best way.
Re: Optimizing Ruby Path Methods
#16don't take this the wrong way, but -- people still use ruby?
It's my daily language and I don't even use rails nowadays.
Re: Optimizing Ruby Path Methods
#17byroot sets a great example sharing his code optimization expertise. His blog has many great improvements like this. A 7x improvement in Dir.join and similar calls?! Thank you, byroot!
Re: Optimizing Ruby Path Methods
#18don't take this the wrong way, but -- people still use ruby?
For pretty much everything. My terminal is in Ruby, with a Ruby font renderer, running Ruby shell, and my editor is in Ruby, my window manager, my file manager. (Yes, I'm taking it a bit far; my prototype Ruby compiler is self-hosting finally, so I guess sometime in the next 20 years I'll end up booting into a Ruby kernel for no good reason...)
I really like Ruby. It had a formative impact on my young programmer self, particularly the culture. So much joyful whimsy.
But like... something like a font renderer in Ruby? The thing that is incredibly cache sensitive and gets run millions of times per day on a single machine? The by far slowest step of rendering any non-monospaced UI?
The Earth is weeping my brother.
Re: Optimizing Ruby Path Methods
#19Earlier quoted context omitted.
For pretty much everything. My terminal is in Ruby, with a Ruby font renderer, running Ruby shell, and my editor is in Ruby, my window manager, my file manager. (Yes, I'm taking it a bit far; my prototype Ruby compiler is self-hosting finally, so I guess sometime in the next 20 years I'll end up booting into a Ruby kernel for no good reason...)
I really like Ruby. It had a formative impact on my young programmer self, particularly the culture. So much joyful whimsy. But like... something like a font renderer in Ruby? The thing that is incredibly cache sensitive and gets run millions of times per day on a single machine? The by far slowest step of rendering any non-monospaced UI? The Earth is weeping my brother.
It doesn't typically get run millions of times per day because in most regular uses it's trivial to cache the glyphs. I use it for my terminal, and it's not in the hot path at all for rendering, as its only run the first time any glyph is rendered at a new size. If you want to add hinting and ligatures etc., it complicates the caching, but I have no interest in that for my use, and then it turns out rendering TrueType fonts is really easy:
https://github.com/vidarh/skrift
(Note that this is a port of the C-based renderer libschrift; the Ruby version is smaller, but much less so than "usual" when converting C code - libscrift itself is very compact)