Performance Tuning for .NET Core
reubenbond.github.io
Performance Tuning for .NET Core
1–10 of 78 posts
Re: Performance Tuning for .NET Core
#2> Reduce branching & branch misprediction
I wrote a parser for a "formalized" URI (it looked somewhat like OData). This parser was being invoked millions of times and was adding minutes to an operation - it dominated the profile at something like 30% CPU time. It started off something like this:
int state = State_Start;
for (var i = 0; i for (var i = 0; i Re: Performance Tuning for .NET Core
#3> Reduce branching & branch misprediction I wrote a parser for a "formalized" URI (it looked somewhat like OData). This parser was being invoked millions of times and was adding minutes to an operation - it dominated the profile at something like 30% CPU time. It started off something like this: int state = State_Start; for (var i = 0; i Hardly rocket science, a clear-as-day miniature state machine. VTune was screami…
> This is something that the "premature optimization crowd" (who tend to partially quote Knuth concerning optimization) get wrong
But this wasn't premature optimisation.
- you found performance was actually a problem in practice
- you used a tool to profile the application for a real workload
- you isolated something to optimise
- you came up with a way to optimise based on the data and your tools
- you tested that the optimisation worked
That isn't premature optimisation. Premature optimisation would have been writing this in the first place without checking anything first.
Re: Performance Tuning for .NET Core
#4> Reduce branching & branch misprediction I wrote a parser for a "formalized" URI (it looked somewhat like OData). This parser was being invoked millions of times and was adding minutes to an operation - it dominated the profile at something like 30% CPU time. It started off something like this: int state = State_Start; for (var i = 0; i Hardly rocket science, a clear-as-day miniature state machine. VTune was screami…
I failed to see how your anecdote relate to your ax-grindy assertion that premature optimization is bad. You wrote your code, you profiled it, you found one function taking 30% of the time, you optimized that function.
Re: Performance Tuning for .NET Core
#5So in other words extreme tuning = do the opposite of what you probably did!
Re: Performance Tuning for .NET Core
#6> Reduce branching & branch misprediction I wrote a parser for a "formalized" URI (it looked somewhat like OData). This parser was being invoked millions of times and was adding minutes to an operation - it dominated the profile at something like 30% CPU time. It started off something like this: int state = State_Start; for (var i = 0; i Hardly rocket science, a clear-as-day miniature state machine. VTune was screami…
> This is something that the "premature optimization crowd" (who tend to partially quote Knuth concerning optimization) get wrong But this wasn't premature optimisation. - you found performance was actually a problem in practice - you used a tool to profile the application for a real workload - you isolated something to optimise - you came up with a way to optimise based on the data and your tools - you tested that t…
[deleted]
Re: Performance Tuning for .NET Core
#7> Mark classes as sealed by default
Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
Re: Performance Tuning for .NET Core
#8> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
I had the same thought when I saw that. There seems to be a trend to seal and lock down classes preventing any kind of extension. It sort of misses one of the main benefits of OOP and I know what I'm doing.
Re: Performance Tuning for .NET Core
#9> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
How do you know it's not been done for a good reason? Designing classes for extensibility is not easy. Furthermore, you can make classes extensible later on, but you can't do the reverse without breaking the API.
Re: Performance Tuning for .NET Core
#10> Reduce branching & branch misprediction I wrote a parser for a "formalized" URI (it looked somewhat like OData). This parser was being invoked millions of times and was adding minutes to an operation - it dominated the profile at something like 30% CPU time. It started off something like this: int state = State_Start; for (var i = 0; i Hardly rocket science, a clear-as-day miniature state machine. VTune was screami…
I failed to see how your anecdote relate to your ax-grindy assertion that premature optimization is bad. You wrote your code, you profiled it, you found one function taking 30% of the time, you optimized that function.
We can always end up with a tautology interpretation of premature optimization, in which case it cannot be bad, if it was bad, it wasn't premature!
While this may no include you, a great many forums and advise areas on the internet, and elsewhere, would discourage you from even worrying about a detail like this. Asking questions about this will just get you a knuth quote. I sometimes wonder if the reason so much software today is inexplicably slow is because for 30 years so many young kids curious about how computers and compilers work were told not to worry about it.
I think it is useful to build up some intuition about these things, so your default implementation can be the fast one when it isn't especially messy to do so. People don't always get the opportunity to come back and change things later, and some design choices don't just affect a single function that you can easily fix later in the development processes.