<FromGitter>
<jrei:matrix.org> Yep works now, @beta-ziliani should be right
taupiqueur has quit [Quit: taupiqueur]
<FromGitter>
<RespiteSage> Not Crystal-specific, but I'm just realizing that I have a gap in my education relating to designing software to restrict its own resource usage (and, in particular, memory usage). Does anyone here know of any good resources for learning about how to do that? I'm thinking more along the lines of "patterns" and "best practices" than specific implementations, but I'm up to learn any of it.
<FromGitter>
<RespiteSage> Oh, and I don't have a specific application this is for (otherwise I'd go for an easier solution like putting it in a resource-constrained container). I just want to know how it's done.
<FromGitter>
<jrei:matrix.org> I guess you already know the common advices like "use structs where possible" and avoiding (heap) allocations by using IOs for example.
<FromGitter>
<RespiteSage> Yeah, I'm looking for guidance about situations where you want to specifically restrict memory (for example) under some value. I do know how to just try and use less memory, but how do I specifically restrict my software to use, e.g., <= 4 GB and still accomplish its task without crashing?
<FromGitter>
<RespiteSage> (GB of RAM, that is)
<FromGitter>
<oprypin:matrix.org> @RespiteSage: really basically nobody does that...
<FromGitter>
<oprypin:matrix.org> almost all software is unequipped to deal with running out of RAM. if you really want to achieve that, you'll be one of the pioneers.
<FromGitter>
<oprypin:matrix.org> all i can think of is some in-memory cache. of course you could tell it to drop the memory when you detect that there isn't enough. but crystal doesn't even have good tools for detecting
<FromGitter>
<jrei:matrix.org> This kind of thoughts are mainly used in embedded environments
<FromGitter>
<jrei:matrix.org> aerospace for example
<FromGitter>
<oprypin:matrix.org> right.. i'm totally unfamiliar with that ⏎ in their case they might even just exactly take account of all the used memory by making arrays have hardcoded sizes, not using heap, etc
<FromGitter>
<jrei:matrix.org> Yeah, they are commonly forbidden to use any heap at all
<FromGitter>
<RespiteSage> Yeah, that makes sense. If computers are just getting more powerful, then why bother with setting restrictions?
<FromGitter>
<jrei:matrix.org> I believe this solves the memory issue? Only using the stack make it predictable
<FromGitter>
<RespiteSage> That is, it makes sense, but I think it's a wasteful perspective.
<FromGitter>
<oprypin:matrix.org> in the cloud world... the way it's dealt with is sending a notification that you're gonna be overcharged for RAM usage, meanwhile let's kill your task and move it to a beefier machine
<FromGitter>
<RespiteSage> Yeah, the two naive solutions I can think of are using only stack and implementing your own heap.
<FromGitter>
<RespiteSage> @oprypin:matrix.org I absolutely agree about how it's done and what makes sense from an operational perspective.
<FromGitter>
<jrei:matrix.org> Yes usually guys with containers limit CPU and memory utilization with the cgroups. Then, the app has to deal with. Either it crashes, or manage to still run but slower.
<FromGitter>
<RespiteSage> My perspective comes from a growing understanding of the (long-term, ecological) cost of continuously producing more powerful computing machinery and a strong desire to learn ways of using what we already have better.
<FromGitter>
<jrei:matrix.org> Can also be done to limit the IO, too
<FromGitter>
<RespiteSage> And I guess I'm willing to try and be a "pioneer", but I feel incredibly unqualified for that.
<FromGitter>
<jrei:matrix.org> There is no golden rule to optimize software. Finding more efficient algorithms is generally a good bet.
<FromGitter>
<jrei:matrix.org> From what I see sometimes there is a tradeoff about RAM usage vs CPU usage
<FromGitter>
<RespiteSage> Yeah, it seems that way. Sorting algorithms are a good example there.
<FromGitter>
<oprypin:matrix.org> @RespiteSage: actually not so much for sorting, i think -- almost all of the widely used ones use a constant (near-zero) amount of memory
<FromGitter>
<rishavs> Thanks! guess there is no way to muck about with strings without creating a new string everytime. Was trying to work on a parser combinator, but strings make it very perf heavy
<FromGitter>
<jrei:matrix.org> You can use a parser, with a IO::Memory buffer
<FromGitter>
<jrei:matrix.org> Then clear it an reuse it to avoid new allocations
<FromGitter>
<oprypin:matrix.org> @rishavs: yea there really is no way to get a `String` to share any memory ever. not even prefix, not even suffix. if you switch everything to IO and Slice, though, that's no problem at all. but of course you lose multiple conveniences.
<FromGitter>
<jrei:matrix.org> For instance, iterate with each_char, then after the n th char store the 2 next ones into a buffer. ⏎ I don't know if it will work better for you
notzmv has quit [Ping timeout: 268 seconds]
<FromGitter>
<rishavs> it does makes things a bit complicated, specially when i need to do ad hoc lookahead. but let me try.
<FromGitter>
<rishavs> Thanks as always for the help
ur5us has joined #crystal-lang
postmodern has quit [Remote host closed the connection]
<FromGitter>
<rishavs> Is there a way to write infix operators?