Reputation
Top tag
Next privilege 15,000 Rep.
Protect questions
Badges
1 23 46
Newest
 Nice Answer
Impact
~597k people reached

Apr
15
comment How to deal with misconceptions about “premature optimization is the root of all evil”?
To answer your question, do not argue with people. Arguments are not won. When I run into people like that, I just express my viewpoint and leave it at that. When we need performance, I knuckle down and fix it, and let the results do the talking. If somebody learns from me, great, but I don't expect it. BTW, talking about opinions - Knuth was just expressing his opinion.
Apr
13
comment How to deal with misconceptions about “premature optimization is the root of all evil”?
+1 I've done performance tuning for decades, and I've written extensively on it in stackexchange (a collection of sites that performs a great public service, IMHO). I wouldn't put it exactly the way you have, but your first two sentences capture the heart of it.
Mar
19
comment How do you handle Performance tasks in Agile?
Treat it as a bug that just happened to be discovered at a late stage. (I am not convinced of the "Agile" methodology, so I would say, let its adherents figure out how to fit this into its plumbing.)
Mar
3
comment Why are eval-like features considered evil, in contrast to other possibly harmful features?
Two upvotes, and two downvotes. Looks like maybe this hits a nerve.
Feb
27
comment What is the ninja performance gap, why is it so large, and how can we overcome it?
People like to get attention with fancy wording. Performance is a simple thing. It is not really something you get ahead of time by thinking about it, but something you do post-hoc, in multiple stages. You may find that you need better algorithms, or parallelism, or other measures, but the key word is find, not assume.
Feb
8
comment “Fuzzy” parsing in different languages
@svick: The nice thing about a trie is it can cycle back on itself, or if you prefer, the recursive walk procedure can cycle back to the top of the trie as a way of handling more than one word in the string, and it can still handle all kinds of misspellings, such as spaces inserted or deleted.
Jan
16
comment How can I test for performance issues in a specific piece of code?
@Zibbobz: What to do: Run it under a debugger, and in the execution phase where it is sluggish, manually interrupt it and examine the call stack. If you do this a few times, it will show you what the problem is. Problems with that duplicate question: Knowing which routines have the highest execution count does not reveal the problem. See point 6 here. Don't assume it's a matter of narrowing down to class and function. Look instead for what it's doing and why.
Jan
16
comment MVC controller and decoupling explained
@Narek: That's the model-view-controller idea, where you can change the view without having to change the model. There can be many different views of the model, or none, so you don't want the model to depend in any way on the ways in which is viewed. To me, that makes a certain sense, except in a situation where the model structure can change frequently. In that case, it is important to minimize the effort to upgrade the corresponding view structure.
Jan
15
comment MVC controller and decoupling explained
@Narek: The idea that M should not "know about" V is so that different Vs can be made more easily. In my experience, changes to M are more likely , and if V is more closely bound to M, the corresponding changes can be done more easily. Ideally, one should not have to have a separate C at all, because all the information needed to specify it is already included in M and V. Sorry it's more than 2 words, but we're talking about an order of magnitude savings in developer effort, which turns into a more responsive dev. cycle.
Jan
14
comment MVC controller and decoupling explained
I know I'm in a contrarian minority, but I have a problem with the idea that decoupling the M, V, and C are a good idea. (I suppose in some/many situations there is no good alternative.) My alternative is here, here, and here, and there is plenty of public code if you're interested.
Nov
23
comment Optimization: How much time saved is considered worth it?
First, does it bother anyone, like a user or you? If not, you don't have a problem, so don't fix it. Second, don't look at absolutes, like minutes or seconds. Look at fractions, like 1%, 10%, or 90%. Saving a minute is worthless if it is spread out over a day, because it is less than 0.1%, and there are certain to be bigger savings elsewhere.
Nov
12
comment In general, is it worth using virtual functions to avoid branching?
@gnasher729: Well, the first thing I do is get stack samples, and on each one, examine what the program is doing and why. Then if it spends all its time in leaves of the call tree, and all the calls are truly unavoidable, does it matter what the compiler and hardware do. You only know method dispatch matters if samples land in the process of doing method dispatch.
Nov
12
comment In general, is it worth using virtual functions to avoid branching?
@gbjbaanb: Everybody says they've got "highly critical sections". How do they know? I don't know something is critical until I take, say, 10 samples, and see it on 2 or more of them. In a case like this, if the methods being called take more than 10 instructions, the virtual function overhead is probably insignificant.
Nov
6
comment In general, is it worth using virtual functions to avoid branching?
The problem with this question is it presupposes that this is big enough to worry about. In real software, performance problems come in big chunks, like slices of pizza of multiple sizes. For example look here. Don't assume you know what the biggest problem is - let the program tell you. Fix that, and then let it tell you what the next one is. Do this half a dozen times, and you might be down to where virtual function calls are worth worrying about. They never have, in my experience.
Nov
4
comment How can I diagnose async/await deadlocks?
Are the deadlocking threads/processes on the same hardware, so you can get simultaneous stack traces as @svick suggested? If A is waiting for something from B, and B is waiting for something from A, this should be clear from examining both of their stacks.
Oct
30
comment Fundamental issues of programming
@DocBrown is right. The supposed tradeoff between performance and maintainability is merely anecdotal. But there's a bigger issue: don't look at performance by taking a magnifying glass to the code. Instead, get it running and then let it tell you what takes time. The bigger the code is, the more likely there are multiple ways to speed it up. Want a surprise? Take a look at this case where the speedup factor is almost 3 orders of magnitude. That's like 20 minutes to 1 second.
Oct
16
comment How can I be quicker at resolving application performance problems
You don't say how you go about choosing what to optimize. You're not alone - most programmers don't know how, and don't know they don't know. They are liable to think it has to do with cache-misses or big-O. Also, they are frustrated that the Agile methods don't seem to allow them to do performance tuning. I do a lot of performance tuning, but it can a frustrating experience just because most programmers don't understand it.
Oct
8
comment Do nested conditionals have a significant performance impact?
Nesting doesn't cost anything. What hurts performance is doing things you don't need to.
Sep
29
comment Performance concern in object oriented languages
Performance problems are never where you think they are. I only know of one absolutely sure-fire can't-miss way to find them, and that is to use a small number of random stack samples. I work in a large C# project, and it has found some large speedups. The point is, assuming there is a real performance problem, no matter what it is, fixing it will save some fraction of time, like from 10% to 90%. The probability you will catch it in the very act on any single sample is at least that large. (It is extremely unlikely to be what you're guessing.)
Sep
9
comment What is O(m+n) and O(m*n) in Big O notation?
@MetaFight: yippee