merge into pattern
So I've read about patterns a bit
I have :
Should I really reformat that as
(my IDE tells me to, cf. screenshot)
why is my IDE so adament on me using them, is there really beneficial about it?
29 Replies
i find the version the IDE is telling you to use much easier to read
at minimum, i would de morgan your logic so you don't need to invert the result
(which the second version already did for you)
(https://en.wikipedia.org/wiki/De_Morgan%27s_laws if you aren't familiar)
yeah that's fair enough
but between i < 5 || i > 7
the pattern is technically less redundant since you only have to specify
i once
but at that point it's more personal preference imoI guess
I was wondering the compiled code won't change right
It is purely aesthetics? (which is fine i'm just curious)
i can't say that off the top of my head but the result of both will 100% be the same
I just checked, the decompiled compiled code goes from
num < 5 || num > 7
to
(num < 5 || num > 7) ? true : false (when using patterns)
so I guess the same lolthe decompiler is just guessing at what the source code might be
ah
Yeah I don't know how to read that
😦
ah there is a xor thing
in the second one
weirdly enough
they are essentially the same thing, though the non-pattern one managed to JIT to a branchless solution
not sure why, you'd need some brains from #allow-unsafe-blocks
A neat advantage though is the compiler can better detect if a pattern is contradictory
yeah, based on this the pattern might be negligibly slower but i think the readability is more important in 99.999% of cases
in the sense that it would never get to True for example i is > 5 and < 2?
Almost unrelated but is there a thing where you give more time to the compiler and it finds a better compiled code?
Im new to compiled languages been doing Python for years so there might not be but I feel like it could make sense?
yes, if a method is called enough the JIT can recompile it with more optimization
Ah but that’s not possible « beforehand »?
i mean, maybe with AOT but that's a different can of worms
I see that’s good though and that persists in between call to the software?
C# doesn't turn directly into assembly code
AOT?
when you compile it turns into IL, then when you run the program that's turned into assembly as needed
which allows it to do smart things like re-optimize code that gets called a lot
The reoptimization is at the IL level?
Or at the assembly level?
no, the assembly level
the IL never changes
ahead of time compilation, it's a way to compile a C# program directly into assembly without the JIT or IL in the end result
but it has some limitations that could be a problem depending on the C#/.NET features you use in the program
it also means the assembly you compiled to is the assembly you get, it can't be progressively optimized at runtime
I see
But if I run the IL on Monday
And I turn off my computer
And I run it on Thursday
Will the optimizations made on Monday
Persist
the assembly code isn't stored
so no
Ah i see
(Sorry if it’s a naive question I’m really no expert)
Is there an easy way to keep the optimizations it made?
Or maybe it wouldn’t even be worth it to?
it's not really needed, though afaik there are ways to pre-generate a profile that can inform the JIT what needs to be optimized more
but that's already getting out of my level of expertise and would be a question for #allow-unsafe-blocks
I see, I'll ask later because I'm still a beginner but I'll keep in mind it might be possible, especially since my team transitioned from Python to C# partially for the added benefit of faster calculations
Thanks!
you'll already get plenty of speed increase from switching to C# without doing anything special, assuming you weren't just using python as glue between native libraries
Yep