• 0 Posts
  • 29 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle
  • I’m no rust expert, but:

    you can use into_iter() instead of iter() to get owned data (if you’re not going to use the original container again). With into_iter() you dont have to deref the values every time which is nice.

    Also it’s small potatoes, but calling input.lines().collect() allocates a vector (that isnt ever used again) when lines() returns an iterator that you can use directly. You can instead pass lines.next().unwrap() into your functions directly.

    Strings have a method called split_whitespace() (also a split_ascii_whitespace()) that returns an iterator over tokens separated by any amount of whitespace. You can then call .collect() with a String turbofish (i’d type it out but lemmy’s markdown is killing me) on that iterator. Iirc that ends up being faster because replacing characters with an empty character requires you to shift all the following characters backward each time.

    Overall really clean code though. One of my favorite parts of using rust (and pain points of going back to other languages) is the crazy amount of helper functions for common operations on basic types.

    Edit: oh yeah, also strings have a .parse() method to converts it to a number e.g. data.parse() where the parse takes a turbo fish of the numeric type. As always, turbofishes arent required if rust already knows the type of the variable it’s being assigned to.







  • Claymore (the end was kinda mid)

    Genuinely curious - why do you like it? I see this at the top anime of all time. I watched it a few years ago and i thought it was absolutely horrible. Like 2 or 3 out of 10.

    I feel like the only reason i can see is “the main character is a bad guy” but that doesnt excuse trope-y terrible writing, flat characters, and mid-2000’s animation that aged horribly. Am i missing something?





  • I’m not sure I understand your point about fall through having to be explicit

    As far as i understand it, every switch statement requires a break otherwise it’s a compiler error - which makes sense from the “fallthrough is a footgun” C perspective. But fallthrough isnt the implicit behavior in C# like it is in C - the absence of a break wouldnt fall through, even if it wasnt a compiler error. Fallthrough only happens when you explicitly use goto.

    But break is what you want 99% of the time, and fallthrough is explicit. So why does break also need to be explicit? Why isnt it just the default behavior when there’s nothing at the end of the case?

    It’s like saying “my hammer that’s on fire isnt safe, so you’re required to wear oven mitts when hammering” instead of just… producing a hammer that’s not on fire.

    From what i saw on the internet, the justification (from MS) was literally “c programmers will be confused if they dont have to put breaks at the end”.


  • the ergonomics expected of modern languages.

    As someone learning c# right now, can we get some of those “modern ergonomics” for switch statements 💀

    I cant believe it works the way it does. “Fallthrough logic is a dumb footgun, so those have to be explicit rather than the default. But C programmers might get confused somehow, so break has to be explicit too”

    I miss fallthrough logic in languages that dont have it, and the “goto case” feature is really sick but like… Cmon, there’s clearly a correct way here and it isnt “there is no default behavior”




  • I feel like it’s like pointers.

    “Variable” refers to the label, i.e. a box that can contain anything (like *ptr is a pointer to [something we dont know anything about])

    Immutable describes the contents, i.e. the stuff in the box cant change. (like int* ptr describes that the pointer points to an int)

    Rust makes it very obvious that there’s a difference between constants and immutable variables, mainly because constants must be compile time constants.

    What do you call it when a variable cant change after its definition, but isnt guaranteed to be the same on each function call? (E.g. x is an array that’s passed in, and we’re just checking if element y exists)

    It’s not a constant, the contents of that label are “changing”, but the label’s contents cant be modified inside the scope of that function. So it’s a variable, but immutable.


  • Saying “non negotiable” doesnt actually hold up in small claims, nor against basic resistance in most cases.

    Look up your local laws, in some places carpets must be replaced at the expense of the landlord every X years, or if there is any kind of damage (caused by regular wear and tear) that could be a trip hazard. Pictures from move-in, carpets not being replaced when you moved in, etc. all help your case.

    Last place i lived, I spent 30 minutes arguing on the phone with my previous landlord over flooring and got my 700 dollars back. Turns out most of the time they only vaguely know the laws they’re quoting, so if you come with confidence, prep, and a willingness to take it to small claims, they’ll fold to save themselves the effort.





  • I did not dismiss it, I said measure the performance yourself.

    Then why does anyone ask anything? Just figure it out yourself. Oh you read a book or went to college? Why? Should have just reinvented computers yourself man. Taking advantage of collective knowledge is for suckers /s

    This means that the code performance is highly dependent on runtime conditions, and needs to be measured in the place where it’s used.

    How is that helpful for OP? For example, if his question was about rust i’d say “options 1 or 2 should be identical for speed”, but if it’s python i’d say “match statements are just chained if/else chains, so a direct array index would be faster”. For another example, in python attribute access is a function call. x.y in a loop is slower than assigning z = x.y outside of the loop and calling z in the loop.

    You can absolutely generalize and have rules of thumb for performance.

    If they already measured, then they would know which one is faster, because they measured it.

    Measurements can have unintuitive results based on the dataset used (which, for benchmarks, usually end up being artificial datasets). OP’s measurements may not have been consistent with their working understanding, thus they ask outside sources to confirm the truth. Idk why you cant just give them the benefit of the doubt and like… answer the question they actually asked? The explanations for “why” that accompany that answer can also be incredibly helpful.

    And all of these optimizations are just as effective after you measure them to see if they’re needed, and they’re no longer premature.

    That implies that these optimizations are harder than doing it the “mundane” way. They’re not.

    Here’s a fun micro optimization for compiled languages: on modern CPUs

    x = x * (arr[0] * arr[1]) in a loop has better performance characteristics than

    x = (x * arr[0]) * arr[1]

    even though they do the same thing (in short, it’s because of the data dependencies for out-of-order execution - compilers wont make this optimization automatically for floats). How much harder is it to write the first one compared to the second one? How much harder to read is the first compared to the second?

    So why would you not just make the first one your default? Now all your future uses of that pattern will perform better, for no extra effort except the amortized cognitive fee of changing your default option.

    Look at OPs question. Could the answer fall under a rule of thumb that they can apply as their default option for a scenario? I’m pretty sure it can. So who cares about “premature” or not?

    The particular question asked by the OP is very very unlikely to have any significant performance impact at all, unless it’s in an extremely hot loop running millions of times per frame

    So instead of answering their question, you assume it isnt impacting performance and they’re just asking for no reason?

    I literally had this exact question about python like 8 months ago. I had a file parser that needed to process different chunks based on a tag. Performance was critical, several thousand files, each ~3mb), the tag dispatch happened about 100,000-300,000 times per file. The original was implemented with if/else. I switched it to match because i thought it was faster, it wasnt. I looked at a lot of threads with answers like yours until stumbling upon dictionary dispatch (i.e. key = tag, value = first class function to call on the tag’s data) and array dispatch.

    That change alone was a 15% performance improvement.

    You have no idea how their program works, what their hot loop is, if they’re just asking out of curiosity, whatever. Just answer their fuckin question my dude. Platitudes are a waste of everyone’s time.