|
Gotta admit that guy has the skills. Talk about being one with the machine!
One sneeze and you're planting corn in the rows he's going to carve in the ground.
|
|
|
|
|
Every time he rolls to the side with cyclic pitch to fly a curve I expect to see grass flying at the tips of the rotor blades. Any real ground contact would be spectacular, but most probably fatal.
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript.
|
|
|
|
|
I'm sending this link to my son who flew NOE for the Army. I'm waiting to see his comments.
Dave.
|
|
|
|
|
Greg Norman: Chainsaw accident sees golfer nearly lose his left hand
Remember kids, a four iron and a chainsaw require a very different action.
|
|
|
|
|
Exactly!
Favourite line: Throw me to them wolves and close the gate up. I am afraid of what will happen to them wolves - Eminem
~! Firewall !~
|
|
|
|
|
He'll never make the cut again
|
|
|
|
|
The last cut is the deepest!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
They're both used to make cut.
New version: WinHeist Version 2.1.0 Beta
Have you ever just looked at someone and knew the wheel was turning but the hamster was dead?
Trying to understand the behavior of some people is like trying to smell the color 9.
I'm not crazy, my reality is just different than yours!
|
|
|
|
|
Greg Norman ducked when someone shouted "Fore!" until he realised it was the nurse telling the surgeon how many finger were missing............ 
|
|
|
|
|
Like APOD, but with a gif : http://imgur.com/gallery/TUkKuhf[^]
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
There's some processing behind that trajectory calculation - and it works!
Someone, somewhere was very, very relieved after a ten year wait-and-see... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
And dumb-ass Apple couldn't turn their computer on Friday morning 12:00 am to take in orders for the iPhone 6!
|
|
|
|
|
Talk about calling your shot! 8-ball, 16 rails, side pocket.
|
|
|
|
|
On news sites seems news blogs are disappearing?
Mostly with left sites? But I could be mistaken?
Anyone else notice?
|
|
|
|
|
ehhhhmmmm... what?
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Eggbert Bartholomew Bligh wrote: Anyone else notice?
No
Within you lies the power for good - Use it!
|
|
|
|
|
Try the ones on the right.
|
|
|
|
|
If you've left the website why do you care what they have or don't have?
|
|
|
|
|
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?"
So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!"
Are you serious? LOL...
Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder.
I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code.
For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes.
To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same:
1) move any repetitive work that's static outside the loop
2) cache objects that are expensive to create and setup
3) cache results that are expensive to calculate
4) don't use reflection in highly trafficked code
5) don't use linq in highly trafficked code
6) don't inline SQL code, use stored procs
7) don't suck down an entire database, only grab the data as you need it
Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list).
I think if you use C# every day, you should know what parts of it are slow.
Also, from my limited experience with profilers, they are more of a waste of time then good. Let's say I have this:
Dictionary<Tuple<string, object>> dict;
and then I have some highly trafficked code that does:
if (dict.TryGetValue(new Tuple<string, object>("someString", 5), out result))
{
}
that's going to be really slow. A profiler is going to show you that 99% of the run time was spent in GetHashCode() and because you don't know how to think without a profiler, you'll be clueless as to what the real problem is. Which is:
1) you're new'ing up an object on every lookup
2) you should always use a simple native object as your dictionary key since compound objects are very expensive to hash (stay away from strings and guids as well).
Thoughts?
|
|
|
|
|
You don't need a profiler to find a problem with this code snippet. 
string ret = string.Empty;
for (int i=0; (i < someLargeInt); i++) {
ret += AMethodThatReturnsAString (i);
}
return ret;
But a profiler can come in mighty handy when trying to identify the bottleneck in complex, old code that no longer seems to scale well.
/ravi
|
|
|
|
|
Well, you rarely inherit an old application and get told "everything in it is slow"... you get told "functionality 1 through x is slow. So you really only identity bottlenecks in specific pieces of code.
|
|
|
|
|
SledgeHammer01 wrote: functionality 1 through x is slow
If only it were as simple as that in reality. 
The enterprise app I work on has several moving parts and is continuously growing. For the most part, it works fine. But once in while we encounter a dataset that causes an unexpected performance problem. A profiler has helped address problems such as these, where the solution isn't immediately obvious. In many cases it's not simply "crappy code" that's to blame, but a lack of understanding of all possible input conditions. Often, this leads to re-engineering parts of the app or modifying workflow rules in order to better handle the load.
BTW, performance analysis is an area in which I don't pretend to have any expertise. At work we have performance engineers who eat, drink and breathe scalability. I take my hat off to them.
/ravi
|
|
|
|
|
OIC... I guess that's why I was wondering if it's "just me" . If I encountered a problem with a specific dataset that was causing a performance issue, I guess I'd do my usual thing with that dataset as the input. The biggest issue I have seen with my limited experience with profilers as I said in my original post is that they generate way too much noise to be useful. By the time you dial it in and filter out all the noise, you could have just as easily done it manually. Then there is the profiler misleading you as well as in my dictionary example. I guess once you do a few a optimization jobs manually, you start to learn where the performance issues are. I was recently surprised to learn that Enum.HasFlags() is a performance killer (such a simple method, you'd think). I found that out during my normal process, but now going forward, I'd know that's one of the items I need to look out for on an optimization job.
|
|
|
|
|
Well said. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
