code performance idea in team environment
-
When you are in a big team, and the code is subject to constant spec changes then well crafted, good performing, lean and mean code is subject to update to messy after thought trash code in the middle that progressively makes the whole code bloatier and slower. Now little apart code review can be done against bloatier code. Hell when a developer that has no clue about the project get pulled in to quickly add a new feature in 2 hours or less (time is money you know) mess creep is to be expected... However... At the very least the developer will make sure his code doesn't throw exception! And now I came up with an idea on how to make sure that performance degradation doesn't creep in unexpectedly! I wrap every must be quick code in a
class TimeCriticalBlock : IDisposablewhich automatically break if code get slower than acceptable (creation parameter). This way, if the code slow down more than acceptable... the developer got an automatic reminder by the system while debugging! :D Quite happy when I came up with that idea! :cool:A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Very interesting.
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
-
Very interesting.
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
Thanks! :) Just posted a link to the very simple classes that do that right above! [The Lounge](https://www.codeproject.com/Lounge.aspx?msg=5350149#xx5350149xx)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Super Lloyd wrote:
Need more buzzwords though!
How about "IoT data acquisition with real time distributed cloud big data document persistence and browser aware critical metrics for empowering performant management decision making." Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
When you are in a big team, and the code is subject to constant spec changes then well crafted, good performing, lean and mean code is subject to update to messy after thought trash code in the middle that progressively makes the whole code bloatier and slower. Now little apart code review can be done against bloatier code. Hell when a developer that has no clue about the project get pulled in to quickly add a new feature in 2 hours or less (time is money you know) mess creep is to be expected... However... At the very least the developer will make sure his code doesn't throw exception! And now I came up with an idea on how to make sure that performance degradation doesn't creep in unexpectedly! I wrap every must be quick code in a
class TimeCriticalBlock : IDisposablewhich automatically break if code get slower than acceptable (creation parameter). This way, if the code slow down more than acceptable... the developer got an automatic reminder by the system while debugging! :D Quite happy when I came up with that idea! :cool:A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I've seen stuff like that and I don't like it. First of all, it obscures code. It's really very annoying to have your code littered with new TimeCriticalBlock(something => { ...}) (or probably something like that). Then comes logging, which is even more clutter. I've seen code that was about 50% diagnostics... And the diagnostics usually didn't even matter (I've never needed it)! Add to that that everything works fine in our own environment, but the customer refuses to invest in a decent server... So in production everything in twice as slow. All those kinds of tests would pass in development and fail in production. And the last thing I want when my code isn't up to speed anyway... Is for it to break as well! That's really adding insult to injury :sigh: Perhaps it would be a nice idea if the code was inserted at compile time (code weaving?) and then stored metrics somewhere and gave the team a warning (email or something) when the code was slower than could be expected on production.
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
I've seen stuff like that and I don't like it. First of all, it obscures code. It's really very annoying to have your code littered with new TimeCriticalBlock(something => { ...}) (or probably something like that). Then comes logging, which is even more clutter. I've seen code that was about 50% diagnostics... And the diagnostics usually didn't even matter (I've never needed it)! Add to that that everything works fine in our own environment, but the customer refuses to invest in a decent server... So in production everything in twice as slow. All those kinds of tests would pass in development and fail in production. And the last thing I want when my code isn't up to speed anyway... Is for it to break as well! That's really adding insult to injury :sigh: Perhaps it would be a nice idea if the code was inserted at compile time (code weaving?) and then stored metrics somewhere and gave the team a warning (email or something) when the code was slower than could be expected on production.
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
First the aesthetics aspect. Apparently you would prefer some kind of (so called) aspect oriented programming over a simple using statement, why not, whatever rocks your boat man! On a "where to put your effort kind of things" aspect is a well known .NET programming technique since at least 2003 (see [Aspect-Oriented Programming](https://msdn.microsoft.com/en-us/library/aa288717(v=vs.71).aspx) ) which has failed to garner much of any success or enthusiasm since then... As far as I am concerned it is not even worth wasting time trying to use. I understand your preferences are different, maybe use [GitHub - Fody](https://github.com/Fody/Fody) , seem to be easy to put into practice... As for the rest why would you pass a callback in the constructor? I am curious as to what were you thinking? For the record here is the implementation I am currently using: [The Lounge](https://www.codeproject.com/Lounge.aspx?msg=5350149#xx5350149xx) Finally all those "tests" (more like debug time code break) are only meant to valid that your code is performant, as you can see on my implementation, whether it runs slow or not on production has little to no effect and is, in theory, completely irrelevant. The idea is to attract and awake the developer attention, much like an exception would.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
First the aesthetics aspect. Apparently you would prefer some kind of (so called) aspect oriented programming over a simple using statement, why not, whatever rocks your boat man! On a "where to put your effort kind of things" aspect is a well known .NET programming technique since at least 2003 (see [Aspect-Oriented Programming](https://msdn.microsoft.com/en-us/library/aa288717(v=vs.71).aspx) ) which has failed to garner much of any success or enthusiasm since then... As far as I am concerned it is not even worth wasting time trying to use. I understand your preferences are different, maybe use [GitHub - Fody](https://github.com/Fody/Fody) , seem to be easy to put into practice... As for the rest why would you pass a callback in the constructor? I am curious as to what were you thinking? For the record here is the implementation I am currently using: [The Lounge](https://www.codeproject.com/Lounge.aspx?msg=5350149#xx5350149xx) Finally all those "tests" (more like debug time code break) are only meant to valid that your code is performant, as you can see on my implementation, whether it runs slow or not on production has little to no effect and is, in theory, completely irrelevant. The idea is to attract and awake the developer attention, much like an exception would.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Ah, didn't see your implementation yet. The using statement certainly makes it better than what I've seen, although using a callback means you can also log any input and output parameters (which is what the code I came across also did). I'm not a fan of AOP, it caused me more trouble than added benefit. I am curious though, why not put the timing in a unit test? That way you can test your code for speed without actually touching your code, but your build will still break. Of course you won't have the benefit of the log statement in production (but how often do you check that, really?).
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
Ah, didn't see your implementation yet. The using statement certainly makes it better than what I've seen, although using a callback means you can also log any input and output parameters (which is what the code I came across also did). I'm not a fan of AOP, it caused me more trouble than added benefit. I am curious though, why not put the timing in a unit test? That way you can test your code for speed without actually touching your code, but your build will still break. Of course you won't have the benefit of the log statement in production (but how often do you check that, really?).
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
In fact putting the speed test in a unit test would be a very good idea! :) Unfortunately in the companies I have been working so far, unit test haven't been a very popular approach. Not that they dislike them mind you! More like they usually fall into disrepair... And on-going new revised specifications put a lot of pressure on maintaining existing ones. I did write some for the low level utilities I created which are still valid (I am often the go to guy for low level utilities) but most of the few high level business model integration tests I have been writing so far have almost all been deprecated by too many model and specifications changes....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Ah, didn't see your implementation yet. The using statement certainly makes it better than what I've seen, although using a callback means you can also log any input and output parameters (which is what the code I came across also did). I'm not a fan of AOP, it caused me more trouble than added benefit. I am curious though, why not put the timing in a unit test? That way you can test your code for speed without actually touching your code, but your build will still break. Of course you won't have the benefit of the log statement in production (but how often do you check that, really?).
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
As for the logs... our acceptance server run as a console app for now, as we are constantly monitoring its output! :D Granted there is way too much output, but it's still readable! ;) Log are also in a file.. But it's easier to read in the console (just click on it) and easier to update the server (just stop, copy files, and restart)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
As for the logs... our acceptance server run as a console app for now, as we are constantly monitoring its output! :D Granted there is way too much output, but it's still readable! ;) Log are also in a file.. But it's easier to read in the console (just click on it) and easier to update the server (just stop, copy files, and restart)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
Log are also in a file.. But it's easier to read in the console (just click on it) and easier to update the server (just stop, copy files, and restart)
Under *nix there is the command tail and graphical or non graphical derivatives; under Windows there are similar utilities (my favourite is baretail). They allow you to "follow" files as they're written and the graphical utilities often have an integrated filtering system to automatically format strings that match a certain criteria (e.g you can put on red background all the strings containing the word "error").
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
-
Super Lloyd wrote:
Need more buzzwords though!
How about "IoT data acquisition with real time distributed cloud big data document persistence and browser aware critical metrics for empowering performant management decision making." Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Yup that should do it :-D
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
-
The article hey? Might do a tips and trick! :^) Meanwhile here are the relevant classes for your information:
public class TimedBlock : IDisposable { Stopwatch stopwatch; public TimedBlock(\[CallerMemberName\] string name = null) { Name = name; stopwatch = new Stopwatch(); stopwatch.Start(); } public string Name { get; set; } public TimeSpan Elapsed { get { return stopwatch.Elapsed; } } public virtual void Dispose() { stopwatch.Stop(); Trace.WriteLine($"TimedBlock({Name}, {Elapsed})"); } } public class TimeCriticalBlock : TimedBlock { TimeSpan max; public TimeCriticalBlock(TimeSpan max, \[CallerMemberName\] string name = null) : base(name) { this.max = max; } public override void Dispose() { base.Dispose(); if (Elapsed > max) { var msg = $"code too slow, {Name} took {Elapsed}."; Trace.Error(msg);#if DEBUG
if (Debugger.IsAttached)
Debugger.Break();
#endif
}
}
}A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
It might be a good idea to convert both of them into
struct's to avoid allocation/GC for each call. This would remove the overhead almost completely (well, for `TimeCriticalBlock` at least, `TimedBlock` writes on each dispose). Also (as others have pointed out), the overhead of writing to the console is also not negligible (it's surprisingly slow, not to mention multithreaded access when you start getting lock contention), using a logging library combined with baretail (or something) might be a better idea. More performant, configurable, able to store logs history for months. Also doesn't lose all logs in case of a crash. -
It might be a good idea to convert both of them into
struct's to avoid allocation/GC for each call. This would remove the overhead almost completely (well, for `TimeCriticalBlock` at least, `TimedBlock` writes on each dispose). Also (as others have pointed out), the overhead of writing to the console is also not negligible (it's surprisingly slow, not to mention multithreaded access when you start getting lock contention), using a logging library combined with baretail (or something) might be a better idea. More performant, configurable, able to store logs history for months. Also doesn't lose all logs in case of a crash.this is a good idea... though generally speaking this overhead would be minimum compare to what it measure business process (with database access, business model, etc...)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Super Lloyd wrote:
Log are also in a file.. But it's easier to read in the console (just click on it) and easier to update the server (just stop, copy files, and restart)
Under *nix there is the command tail and graphical or non graphical derivatives; under Windows there are similar utilities (my favourite is baretail). They allow you to "follow" files as they're written and the graphical utilities often have an integrated filtering system to automatically format strings that match a certain criteria (e.g you can put on red background all the strings containing the word "error").
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
yeah tail is good.. but it's not like using the console here is a no brainer here! :laugh:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
When you are in a big team, and the code is subject to constant spec changes then well crafted, good performing, lean and mean code is subject to update to messy after thought trash code in the middle that progressively makes the whole code bloatier and slower. Now little apart code review can be done against bloatier code. Hell when a developer that has no clue about the project get pulled in to quickly add a new feature in 2 hours or less (time is money you know) mess creep is to be expected... However... At the very least the developer will make sure his code doesn't throw exception! And now I came up with an idea on how to make sure that performance degradation doesn't creep in unexpectedly! I wrap every must be quick code in a
class TimeCriticalBlock : IDisposablewhich automatically break if code get slower than acceptable (creation parameter). This way, if the code slow down more than acceptable... the developer got an automatic reminder by the system while debugging! :D Quite happy when I came up with that idea! :cool:A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
This way, if the code slow down more than acceptable... the developer got an automatic reminder by the system while debugging!
Its a great idea, but I don't think it'll do anything meaningful. In my experience, most algorithmic slowdown isn't because a single operation takes oodles longer than it used to, but because many iterations are done on some code that's just a slight bit slower than it used to be. I guess if you have strict performance goals on certain operations that don't depend on input data, and can limit the timing checking to only measuring debug/release & executed-in-debugger/not-executed-in-debugger & with-breakpoints-set/with-no-breakpoints set, then yeah, maybe it would be useful. Like others have said, measuring performance really is a job for a unit test, where all that can be controlled.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
Ah, didn't see your implementation yet. The using statement certainly makes it better than what I've seen, although using a callback means you can also log any input and output parameters (which is what the code I came across also did). I'm not a fan of AOP, it caused me more trouble than added benefit. I am curious though, why not put the timing in a unit test? That way you can test your code for speed without actually touching your code, but your build will still break. Of course you won't have the benefit of the log statement in production (but how often do you check that, really?).
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
The using statement certainly makes it better
Hi, Sandor, I'm curious: I don't see any use of 'using in the code; are you referring to the use of the '#if DEBUG' compiler directive ?
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
-
Sander Rossel wrote:
The using statement certainly makes it better
Hi, Sandor, I'm curious: I don't see any use of 'using in the code; are you referring to the use of the '#if DEBUG' compiler directive ?
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
It's the usage of the class.
using (new TimedBlock())
{
// Your time critical code here.
}:) Also, you're consistently spelling my name wrong.
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
What you really need is to provide every developer with an IoT device that measures their performance. Then management can sit back and watch the performance degrade as each new patch is made, all on a pretty web-socket / SignalR enabled realtime website. And while you're at it, the integrated build process can run Visual Studio's code analysis. Degrading performance. Increasing complexity. :) Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Exacerbating the debacle again Marc?
Software Zen:
delete this;
