13 ms·

Laws of Performant Software

139 points by sidcool 10y ago

foxhop 10y ago
Performant is not an adjective, it is a noun. "One who performs". Software can perform poor or well. Performant does not mean it performs well. http://weblogs.asp.net/jongalloway/performant-isn-t-a-word http://weblogs.asp.net/jongalloway/performant-isn-t-a-word This matters. Software can perform well at its job (not crash, get the correct answer) but may not perform efficiently (takes a long time, has unbounded resource use, uses a brute force pattern).
- lucozade 10y ago
  Unless it's being used an an adjective, in which case it's an adjective.
- ulber 10y ago
  If you subscribe to descriptive linguistics at all (which you must if you believe languages can naturally change) a quick google search reveals that performant is actually very much an adjective (i.e. it is commonly used as one to the point that one would be considered obtuse to refuse to recognize it as such). To be fair one can also find a fair number of discussions about whether performant is a word in that google search, so "performant as an adjective" is clearly a newish use of the word. Edit: after reading your reference I can comment that journal/book editors mostly do not subscribe to descriptive linguistics and it is probably good that they do not (to not take chances with parts of language that might turn out to be fads).
  - gsnedders 10y ago
    There are plenty of published journals going back decades that accept performant as a term of art.
  - adrianratnapala 10y ago
    Your edit is a good pont. The prescriptive/descriptive dichotomy always seems a bit odd. If you are a linguist: i.e a social scientist who job it is to explain how languages work in this world. Then you must describe. If you are a language teacher then your job is to prescribe. And you make a good point that journal editors have good reasons to do the same. (Especially when looking after authors from STEM fields!)
- rubidium 10y ago
  http://xkcd.com/1735/ http://xkcd.com/1735/
  - aslammuet 10y ago
    This is in fact not a discussion about the semantics of performant.
    - JoeAltmaier 10y ago
      It was made into one.
    - ryandrake 10y ago
      By using "performant" in the title (which is known to set off the language nazis), the author is practically begging for the discussion to devolve into this tangent. It's imprecise: What is it even supposed to mean? Because it's a made-up word, who knows for sure? Does it mean "better performing?" If so, why not just say that? It's not that many more keystrokes. Better performing in what way? CPU? Resource utilization? Say so. You've put a lot of thought and effort into writing something, why blow it by using an imprecise pseudo-word? The author is undermining his own credibility, telling us "I don't care enough about the topic to even pick an actual word, let alone summarize, in more detail, what I mean to discuss."
      - c22 10y ago
        I wonder which words were not made up. The true name of God?
      - MaulingMonkey 10y ago
        All words are "imprecise" and "made-up". My understanding is that performant is totally legal French, meaning efficient or effective, with usage dating back at least 4 decades. If you're not into stealing random words from other languages, I have to question why you're into English in the first place.
  - p333347 10y ago
- rossitter 10y ago
  > Performant is not an adjective, it is a noun. "One who performs". It has been used as a noun, but rarely. You are thinking of the -ant formation seen in informant: one who informs. But this is not the only -ant in English, and it is not the one used here. That which is resistant, resists well; it offers a good amount of resistance. Those who are insistent, insist strongly; they make plenty of insistence. That which is compliant, complies fully; it is very much in compliance. That which is performant, performs well; it offers (a) good performance. As to what good performance is: > Software can perform well at its job (not crash, get the correct answer) but may not perform efficiently (takes a long time, has unbounded resource use, uses a brute force pattern). This is a reasonable objection—I agree with it, wanting speech to be plain—but here is something to oppose it: I suspect that just about everyone who clicked on this article, including the two of us, knew precisely what the author wanted the word to mean, even if they had an objection to that use of the word. Performant has sprung to life, and it describes an efficient performance. As for what I think of the word: the English language is already rich with others which would do just as well, which is probably why this one seems so jargony. It is one of those technical words that sounds more like a social signal—"I know what I'm talking about"—than something precise: "This is what I'm talking about."
- qsymmachus 10y ago
  Fight the real enemy, like the word "learnings"
deleted 10y ago
[deleted]
MyNameIsFred 10y ago
While I agree with the author and like the article, I suspect that it would only make sense to people who already accept these things as true.
- hackits 10y ago
  If you chase two rabbits you will not catch either one. Little bit of background here before I begin. I did my comp-sci and mathematics degree and even though they have been useful in some degree or another they both were mostly a complete waste of time in my experience. For the vast majority of the clients and projects that I've had since finishing my university they've all revolved around fixing framework problems or bugs within large code bases. Just today I fixed a massive Land Titling (Enterprise Java/Oracle) bug where the original underlying framework would leak connections/memory until it fell over after 3-4 hours of usage. Other bugs such as off by 1 problems, data translation, data encoding. The vast majority of the time its been incorrectly designed frameworks or replacing frameworks with another framework. For most of the work out there (I would guess 90% of it) its maintaining and supporting clients to achieve their business goals. Completely un-interesting stuff but get a good reputation of getting stuff done and they don't even wink at your asking price.
sillysaurus3 10y ago
Do threads pass data among themselves? Use blocking queues whose capacity is a function of the max amount of data that can potentially be waiting without exhausting the memory. I.e. a ringbuffer. The Disruptor is an efficient and simple way to coordinate this. https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/
- brianwawok 10y ago
  Disruptor is nonblocking. I think the OP is talking about actual blocking queues which are generally bad in high performance code.
  - sillysaurus3 10y ago
    Disruptor blocks when the ringbuffer fills up.
    - brianwawok 10y ago
      Touchè. Most people size it large enough to never block on insert, so it is usually considered a non-blocking queue. Reads never block for example.
critium 10y ago
While this article is itself worth a read, remember the programming mantra: * Make it Work * Make it Right * Make it Fast And this is the last step. While this does not apply to all projects but it does apply to the majority.
- svdree 10y ago
  What you'll often find however, is that in the last step ("make it fast") you have limited room to maneuver, because of the stuff you did in the first 2 steps. If you really need high performance, you need to design for high performance, not just leave it as an afterthought.
  - critium 10y ago
    absolutely agree with your last sentence. But thats not a majority of software written in my experience. "If you really need *high performance*, you need to design for high performance, not just leave it as an afterthought." Emphasis, mine.
    - jackmott 10y ago
      Then why do I encounter slow software every day? Why do we keep encouraging this?
      - rakoo 10y ago
        Because there is no user story for "make it performant", and there is little thought put into dynamic design vs static design. If money comes in with crappy performance and it is hard to predict how much more money will come if the developer improved performance, then it won't be a business priority.
      - lostcolony 10y ago
        Because they stopped at step one (make it work) or two (make it right). Or the first of my three (borrowed from Joe Armstrong), make it work, make it beautiful. It's not simply that they failed to plan for performance, it's that after making it work -they never measured and removed obvious bottlenecks-. Most pieces of software don't need high performance. Drawing some widgets on screen just isn't that demanding. But it -does- require you to go back afterwards and remove places you introduced inefficiencies. You don't need to code in C and optimize against cache misses for that; you just need to take time after things work to make them not suck, and thats something a lot of software development doesn't take the time to do.
throwawayReply 10y ago
> a cache can be added in 10 LOCs Yes, and then 10 months debugging edge cases where communicating parts are looking at different versions of the "same" data. Caching is really important, but caching (and cache-invalidation) is really difficult, adding caching to an application that doesn't use caching is not "10 LOC and done".
- huhtenberg 10y ago
  > caching (and cache-invalidation) is really difficult That's an urban legend. Needlessly complicated or over-abstracted general-purpose caching frameworks are difficult, but your dumbest imaginable linear LRU fast lookup is both exceptionally useful and can indeed be done in 10 LoC in a lot of cases.
  - throwawayReply 10y ago
    It's not the algorithm that's difficult, it's the effect of adding caching to a system that wasn't built with caching in place at the start that is difficult. This isn't an "urban legend" it's first hand experience working with companies trying to add caching. No, those companies aren't even trying to write caching algorithms, they're just bundling in a caching layer and hoping that the system behaves in the same way. It only takes somewhere which writes data (perhaps in a way that bypasses the caching layer so the cache doesn't know it has changed) and re-reads it back quickly for software which used to work suddenly breaks. Now you might look at that and go "omg refactor it! That's horrible code, that should never ship" etc, but not everywhere is the s.v. bubble with endless amounts of the best developers to throw at problems. Code which worked and solved a business problem ended up shipping, possibly without testers and probably without code reviews. So adding a caching layer suddenly "breaks" those reports, now who's going to have to fix it, not the person who wrote those reports even if the very behavior of side-effected data changes and db re-reads is precisely a cause of data layer slowness that led to wanting to implement caching...
    - sqeaky 10y ago
      > It only takes somewhere which writes data (perhaps in a way that bypasses the caching layer so the cache doesn't know it has changed) and re-reads it back quickly for software which used to work suddenly breaks. So those 10 lines need to be in the wrong place? Why expose the uncached API? Web or single system implement caching in a defined is easy if you don't have a defined API you probably don't have a good system. If you don't have a good system, why are you trying to implement caching? The not being good part is probably why its slow.
kod 10y ago
Isnt item 4 basically encouraging microbenchmarks? Microbenchmarks can be misleading, and there's no guarantee you're benchmarking the important things. It mentions profilers in passing, but i find it more productive to start with a profiler.
signa11 10y ago
but there is no such word as 'performant' ! wiktionary doesn't count :) note that efficiency and performance are _not_ the same thing. improving efficiency implies doing less work for the same end-goal. thus, when a program is 'efficient' then it is doing the minimum amount of work that the computation demands. or in other words, we have the best algorithm around for some kind of complexity argument for the task at hand. an algorithm which is efficient is not wasting anything. performance on the other hand, implies, how quickly the work that is to be done is actually done. basically performance improvement would allow you to do the same amount of work faster (in time). is the program at any given point in time (during its execution) doing maximal speed of work ? that doesn't seem to make much sense. infact, in practical terms, what is the 'maximal speed' of work ? <theoretical constructs like Bremermann's Limit doesn't count :)> programs can perform 'well enough', but that doesn't mean we are all done with it...
- wodenokoto 10y ago
  Performance us actually much,much broader than the speed at which a task is completed. The performance of a classifier can be anything from how fast it runs, to its F1 classification score.
  - signa11 10y ago
    > The performance of a classifier can be anything from how fast it runs, to its F1 classification score. but classification performance would be the efficiency of a classifier algorithm right ? i.e. can i get better classifications / generalizations etc. in lesser time.
    - wodenokoto 10y ago
      Yes and no. It can be better in less time, it can also be just better or just faster (but worse) all depending on what is important. Classifier A gets F1 score of 0.93 on test set has a lower performance than classifier B, which gets an F1 score of 0.94, regardless of time. However, you can also say that classifier C, which only achieves an F1 score of 0.929 has better performance, since it is four times as fast.
cs702 10y ago
I would add another law: Code organized in small, easy-to-read chunks >> code organized in long, dense chunks.
- xixi77 10y ago
  I would even say code organized in small, easy-to-read chunks >> code organized in long, dense chunks >> code organized in lots of tiny, impossible to read (because calls go back and forth all over the place) chunks :)
  - cs702 10y ago
    OMG, Yes!
daemonk 10y ago
From a data analysis perspective (which seems like some of her rules are related to), my number one rule that I always try to follow is to: work with the data, not with the tools. It can be really easy to go down the rabbit hole of messing about with the perfect tool for your analysis and end up with no results. Optimization is important so far as you need it. If I can launch a bunch of aws instances to get a single-run job done in an hour, then I'll throw hardware at the problem instead of worrying about my code. I care about the analysis results, not necessarily how performant my method is. If I'll need to run the analysis multiple times or I plan to publish it as a tool, then thats another story.
- gwbas1c 10y ago
  A common recurring theme in my career are horribly-performing applications because the original programmers worked with an ORM instead of the database. Database code isn't hard! An HBM file is just as complicated as handling a data reader! Stored procedures (or in-line SQL) are simpler in the long run!
  - ansgri 10y ago
    I also don't get the ORM stuff: typically you work either (1) with lots of different objects organized in some kind of document (in NoSQL sense), and you want all these objects to be predictable, free from side effects and clearly serializable to e.g. JSON, or (2) with bulk data which you transform and aggregate to come with a small collection of fully constructed (also, denormalized) objects, and for this purpose SQL is beautiful. Or else they wouldn't've invented Linq to Collections.
tofflos 10y ago
I believe there should be a stronger distinction between decent performance and high performance. Most frameworks coupled with idiomatic code will give you decent performance. I find controlled experiments / microbenchmarks to be a useful method for finding the initial bottlenecks of a system. Once I know the initial bottlenecks I can make an informed descision on whether that performance is sufficient. Controlled experiments / microbenchmarks are also essential in establishing a ballpark number for the theoretical maximum performance of your system. From that point on, the performance is yours to lose.
catnaroek 10y ago
> It is critical that people question “how does this magic actually work?” No. It's critical that people question “why do I have to rely on magic?” in the first place. Even in high-level languages, perhaps especially in high-level languages, it's a good idea to write straightforward code. > there is an appalling lack of candy in the C/C++ ecosystem (...) performance isn’t hidden C and C++ are very different languages, and there is no shortage of C++ libraries full of incomprehensible magic. When debugging template-heavy C++ code, it can be very hard to determine where expensive and unnecessary object copies are created. Thank you C++, for making copy construction implicit! > Are you producing too much garbage unnecessarily? The high-level programmer's best defense against creating too much garbage is programming with values (whose redundant representations in memory can be automatically deduplicated by the runtime system) rather than object identities. > Are your dictionaries too big to the point of being inefficient? The problem isn't the dictionary abstraction, but rather the implementor's choice of underlying data structure. If you have a really big dictionary whose keys are strings (a common use case), you want tries, not hashtables. > string concats can be replaced by string builders in the same amount of lines, Using string builders is a low-level chore, and defeats the point to using a high-level language. A better alternative is using a persistent list/string data structure that actually supports efficient concatenation. > Does your program start ad-hoc threads? Use a threadpool with fixed size. Again, too low-level. A programmer working with a high-level language should be able to spawn as many green threads as she wants to, and let the language's runtime system handle multiplexing those green threads over OS threads. > Unless you are 100% sure the lines are always of reasonable size, do not use readline. This is terrible advice. If readline is causing you problems, you are using the wrong string data structure. --- Okay, I'm done bashing what could be bashed. The last two items in the OP are actually good.
- perfmode 10y ago
  > Again, too low-level. A programmer working with a high-level language should be able to spawn as many green threads as she wants to, and let the language's runtime system handle multiplexing those green threads over OS threads. Do this in Go and you'll be surprised how quickly you run out of memory.
overgard 10y ago
Rule #1 is bogus. If you're starting with a language that's 2-10x slower you're always going to be behind the curve. There's a reason C and fortran haven't gone anywhere.
- OskarS 10y ago
  You're not wrong, but in the real world it frequently happens that the choice of language is not the bottleneck. The bottlenecks are usually things like memory, network and file I/O, making the language you write in make very little difference.
  - klodolph 10y ago
    Well... if memory is the bottleneck, and you use a language implementation where all the integers are heap-allocated, things are not looking good. I would say that choice of language can important if your bottlenecks are CPU, memory, or maximum latency.
- squeaky-clean 10y ago
  > If you're starting with a language that's 2-10x slower you're always going to be behind the curve. I got involved in a huge discussion about optimizing a web app recently. Things that were learned from the conversation? 1) It turns out moving more frequent cases to the top of an 'if-else' chain in JavaScript offers a greater speedup than I expected. 2) It doesn't matter if you shave 4ms off a request by optimizing your if-else chain if a little later in your code you make 27,000 database queries when you could have made 2. Knowing how to write a performant app will always be better than writing sloppy code in the fastest means possible.
  - tomsmeding 10y ago
    27000 instead of 2 database queries would seem to be more than just a performance problem...
    - sokoloff 10y ago
gens 10y ago
gens's* law of writing software that performs well: Don't be smart. Do simple data structures where you can. Arrays, AoA, SoA, AoS. Process data in bulk where you can. Put complex algorithms only where needed (kd-tree when doing something like raytracing, threading only when necessary and even then only with bulk processing, complex locking or timing mechanisms only when you have to, etc.). Don't follow paradigms blindly. Basically data should be processed only in a functional way or in "waves". When there are only a handful of variables, a functional way will keep them in cpu registers. When there is more data, going over an array will make the cpu load the data that is to come next into the cache. Oh, and write C. [*] gens is a hobby programmer and possibly an idiot
marknadal 10y ago
Glad this submission is being upvoted but I think there is room for more practical and direct advice. Here are some resources for JS: - https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k... - https://github.com/amark/gun/wiki/100000-ops-sec-in-IE6-on-2GB-Atom-CPU https://github.com/amark/gun/wiki/100000-ops-sec-in-IE6-on-2... - http://danieltao.com/lazy.js/ http://danieltao.com/lazy.js/
adrianratnapala 10y ago
What is the difference between "performant" and "fast"? If we were talking about cars, then I would say performance includes not only speed but all kinds of things to do with handling. But in computing it always seems to mean "speed"[1], and "performant" always seems to be a bizarre neologism for "fast". I think people invented it because speed is a many faceted thing. There is latency, there is thoughput, there is user-visible responsiveness, all at multiple interacting levels. But these complexities and vaguenesses apply equally to the quasi-word "performant". [1] Actually the main article is a partial exception as she inconsistently includes stability within "performance". In one sentence she says "...performance degradation, including crashes, and the unbounded use of resources." But later she says "Code that doesn’t perform, or that crashes."
- TickleSteve 10y ago
  fast == absolute. performant == relative (efficient on the hardware available). e.g. an algorithm may be performant on a little Cortex-M but certainly is not fast compared to the same code on an I7.
  - adrianratnapala 10y ago
    The problem with this definition is that it isn't true. 17km/hour is an absolute speed. It is fast for a runner, OK for a cyclist and slow for a car. "Fast" is relative.
    - TickleSteve 10y ago
      I agree in that context.... but in the context the original sentence was used, the statement stands. English is not the most precise language....
rahilb 10y ago
Forget _laws_, I just want to know how the dlang forum is so fast.
YZF 10y ago
- Programming language does matter. You will not be able to get the same performance in any programming language you choose. - Abstractions are the enemy of performance. You can't get high performance through many layers of abstraction. This relates to my previous point. - Algorithmic complexity matters when dealing with large data sets. Abstractions can hide the true complexity. (e.g. the famous string append example from IIRC Joel Spolsky). So the key to high performance software is: - As close as possible to the hardware. - The right data structures/layout (taking into account the hardware). - The right algorithms. - Measure properly and optimize.
- sshumaker 10y ago
  I think your point around abstractions could be more nuanced. The wrong abstractions can be deleterious to performance, thoughtfully chosen ones can actually be beneficial. Every programming language is several layers of abstraction above the hardware it runs on, which gives the compiler opportunities for optimization, or even the superscalar CPU opportunities for parallelization / reordering. And so on.
  - YZF 10y ago
    I've yet to see a compiler that can beat a human hand-optimizing. It's true that for zero effort the compiler can usually do better but if you really care about performance you need to get around those abstractions. I worked on a wavelet video decoder, after a while we had a pretty optimized C code that used SSE intrinsics for large portions of the decode. Some clever guy spent 3 months and rewrote the entire decoder in assembly. It involved careful data layout and optimizing the instruction sequences. It ran more than twice as fast than our hand optimized C code. Same algorithm, input and output.
- flukus 10y ago
  I'd make that last key number 1.
- taneq 10y ago
  > Abstractions are the enemy of performance. You can't get high performance through many layers of abstraction. This relates to my previous point. This depends on the kind of abstraction. Layers and layers of crap will never be fast. The correct stack of abstractions, which map well to your problem space, will usually make your code faster because they will make it easier for you to see higher-level optimizations. > Algorithmic complexity matters when dealing with large data sets. Abstractions can hide the true complexity. (e.g. the famous string append example from IIRC Joel Spolsky). Very true. Abstractions are a tool to help understand the problem space, not an excuse to avoid understanding it. > Measure properly and optimize. A+. If you can't measure it, you can't control it. It boggles me how many people don't get this. "I replaced all the floating point math with integer math because integer math is faster." Really? IS IT? How do you KNOW? Did you benchmark it? "No but..." ahem sorry, I've had this argument too many times. :P
syngrog66 10y ago
related to this you may want to check out my cheatsheet PDF on software performance & scalability: http://synisma.neocities.org/perf_scale_cheatsheet.pdf http://synisma.neocities.org/perf_scale_cheatsheet.pdf welcome feedback and ideas for things to add or change
BigJeffeRonaldo 10y ago
Why do English-speaking computer people decide to take an English word like performing, add a random French ending, and use their weird word everywhere? Do they think think it sounds better? Programmers need to study more humanities and literature in school so they can learn what their languages sound like

139 points by sidcool 10y ago

Performant is not an adjective, it is a noun. "One who performs". Software can perform poor or well. Performant does not mean it performs well. http://weblogs.asp.net/jongalloway/performant-isn-t-a-word http://weblogs.asp.net/jongalloway/performant-isn-t-a-word This matters. Software can perform well at its job (not crash, get the correct answer) but may not perform efficiently (takes a long time, has unbounded resource use, uses a brute force pattern).

lucozade 10y ago
Unless it's being used an an adjective, in which case it's an adjective.
ulber 10y ago
If you subscribe to descriptive linguistics at all (which you must if you believe languages can naturally change) a quick google search reveals that performant is actually very much an adjective (i.e. it is commonly used as one to the point that one would be considered obtuse to refuse to recognize it as such). To be fair one can also find a fair number of discussions about whether performant is a word in that google search, so "performant as an adjective" is clearly a newish use of the word. Edit: after reading your reference I can comment that journal/book editors mostly do not subscribe to descriptive linguistics and it is probably good that they do not (to not take chances with parts of language that might turn out to be fads).
- gsnedders 10y ago
  There are plenty of published journals going back decades that accept performant as a term of art.
- adrianratnapala 10y ago
  Your edit is a good pont. The prescriptive/descriptive dichotomy always seems a bit odd. If you are a linguist: i.e a social scientist who job it is to explain how languages work in this world. Then you must describe. If you are a language teacher then your job is to prescribe. And you make a good point that journal editors have good reasons to do the same. (Especially when looking after authors from STEM fields!)
rubidium 10y ago
http://xkcd.com/1735/ http://xkcd.com/1735/
- aslammuet 10y ago
  This is in fact not a discussion about the semantics of performant.
  - JoeAltmaier 10y ago
    It was made into one.
  - ryandrake 10y ago
    By using "performant" in the title (which is known to set off the language nazis), the author is practically begging for the discussion to devolve into this tangent. It's imprecise: What is it even supposed to mean? Because it's a made-up word, who knows for sure? Does it mean "better performing?" If so, why not just say that? It's not that many more keystrokes. Better performing in what way? CPU? Resource utilization? Say so. You've put a lot of thought and effort into writing something, why blow it by using an imprecise pseudo-word? The author is undermining his own credibility, telling us "I don't care enough about the topic to even pick an actual word, let alone summarize, in more detail, what I mean to discuss."
    - c22 10y ago
      I wonder which words were not made up. The true name of God?
    - MaulingMonkey 10y ago
      All words are "imprecise" and "made-up". My understanding is that performant is totally legal French, meaning efficient or effective, with usage dating back at least 4 decades. If you're not into stealing random words from other languages, I have to question why you're into English in the first place.
- p333347 10y ago
rossitter 10y ago
> Performant is not an adjective, it is a noun. "One who performs". It has been used as a noun, but rarely. You are thinking of the -ant formation seen in informant: one who informs. But this is not the only -ant in English, and it is not the one used here. That which is resistant, resists well; it offers a good amount of resistance. Those who are insistent, insist strongly; they make plenty of insistence. That which is compliant, complies fully; it is very much in compliance. That which is performant, performs well; it offers (a) good performance. As to what good performance is: > Software can perform well at its job (not crash, get the correct answer) but may not perform efficiently (takes a long time, has unbounded resource use, uses a brute force pattern). This is a reasonable objection—I agree with it, wanting speech to be plain—but here is something to oppose it: I suspect that just about everyone who clicked on this article, including the two of us, knew precisely what the author wanted the word to mean, even if they had an objection to that use of the word. Performant has sprung to life, and it describes an efficient performance. As for what I think of the word: the English language is already rich with others which would do just as well, which is probably why this one seems so jargony. It is one of those technical words that sounds more like a social signal—"I know what I'm talking about"—than something precise: "This is what I'm talking about."
qsymmachus 10y ago
Fight the real enemy, like the word "learnings"

deleted 10y ago

[deleted]

MyNameIsFred 10y ago

While I agree with the author and like the article, I suspect that it would only make sense to people who already accept these things as true.

hackits 10y ago
If you chase two rabbits you will not catch either one. Little bit of background here before I begin. I did my comp-sci and mathematics degree and even though they have been useful in some degree or another they both were mostly a complete waste of time in my experience. For the vast majority of the clients and projects that I've had since finishing my university they've all revolved around fixing framework problems or bugs within large code bases. Just today I fixed a massive Land Titling (Enterprise Java/Oracle) bug where the original underlying framework would leak connections/memory until it fell over after 3-4 hours of usage. Other bugs such as off by 1 problems, data translation, data encoding. The vast majority of the time its been incorrectly designed frameworks or replacing frameworks with another framework. For most of the work out there (I would guess 90% of it) its maintaining and supporting clients to achieve their business goals. Completely un-interesting stuff but get a good reputation of getting stuff done and they don't even wink at your asking price.

sillysaurus3 10y ago

Do threads pass data among themselves? Use blocking queues whose capacity is a function of the max amount of data that can potentially be waiting without exhausting the memory. I.e. a ringbuffer. The Disruptor is an efficient and simple way to coordinate this. https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/

brianwawok 10y ago
Disruptor is nonblocking. I think the OP is talking about actual blocking queues which are generally bad in high performance code.
- sillysaurus3 10y ago
  Disruptor blocks when the ringbuffer fills up.
  - brianwawok 10y ago
    Touchè. Most people size it large enough to never block on insert, so it is usually considered a non-blocking queue. Reads never block for example.

critium 10y ago

While this article is itself worth a read, remember the programming mantra: * Make it Work * Make it Right * Make it Fast And this is the last step. While this does not apply to all projects but it does apply to the majority.

svdree 10y ago
What you'll often find however, is that in the last step ("make it fast") you have limited room to maneuver, because of the stuff you did in the first 2 steps. If you really need high performance, you need to design for high performance, not just leave it as an afterthought.
- critium 10y ago
  absolutely agree with your last sentence. But thats not a majority of software written in my experience. "If you really need *high performance*, you need to design for high performance, not just leave it as an afterthought." Emphasis, mine.
  - jackmott 10y ago
    Then why do I encounter slow software every day? Why do we keep encouraging this?
    - rakoo 10y ago
      Because there is no user story for "make it performant", and there is little thought put into dynamic design vs static design. If money comes in with crappy performance and it is hard to predict how much more money will come if the developer improved performance, then it won't be a business priority.
    - lostcolony 10y ago
      Because they stopped at step one (make it work) or two (make it right). Or the first of my three (borrowed from Joe Armstrong), make it work, make it beautiful. It's not simply that they failed to plan for performance, it's that after making it work -they never measured and removed obvious bottlenecks-. Most pieces of software don't need high performance. Drawing some widgets on screen just isn't that demanding. But it -does- require you to go back afterwards and remove places you introduced inefficiencies. You don't need to code in C and optimize against cache misses for that; you just need to take time after things work to make them not suck, and thats something a lot of software development doesn't take the time to do.

throwawayReply 10y ago

> a cache can be added in 10 LOCs Yes, and then 10 months debugging edge cases where communicating parts are looking at different versions of the "same" data. Caching is really important, but caching (and cache-invalidation) is really difficult, adding caching to an application that doesn't use caching is not "10 LOC and done".

huhtenberg 10y ago
> caching (and cache-invalidation) is really difficult That's an urban legend. Needlessly complicated or over-abstracted general-purpose caching frameworks are difficult, but your dumbest imaginable linear LRU fast lookup is both exceptionally useful and can indeed be done in 10 LoC in a lot of cases.
- throwawayReply 10y ago
  It's not the algorithm that's difficult, it's the effect of adding caching to a system that wasn't built with caching in place at the start that is difficult. This isn't an "urban legend" it's first hand experience working with companies trying to add caching. No, those companies aren't even trying to write caching algorithms, they're just bundling in a caching layer and hoping that the system behaves in the same way. It only takes somewhere which writes data (perhaps in a way that bypasses the caching layer so the cache doesn't know it has changed) and re-reads it back quickly for software which used to work suddenly breaks. Now you might look at that and go "omg refactor it! That's horrible code, that should never ship" etc, but not everywhere is the s.v. bubble with endless amounts of the best developers to throw at problems. Code which worked and solved a business problem ended up shipping, possibly without testers and probably without code reviews. So adding a caching layer suddenly "breaks" those reports, now who's going to have to fix it, not the person who wrote those reports even if the very behavior of side-effected data changes and db re-reads is precisely a cause of data layer slowness that led to wanting to implement caching...
  - sqeaky 10y ago
    > It only takes somewhere which writes data (perhaps in a way that bypasses the caching layer so the cache doesn't know it has changed) and re-reads it back quickly for software which used to work suddenly breaks. So those 10 lines need to be in the wrong place? Why expose the uncached API? Web or single system implement caching in a defined is easy if you don't have a defined API you probably don't have a good system. If you don't have a good system, why are you trying to implement caching? The not being good part is probably why its slow.

kod 10y ago

Isnt item 4 basically encouraging microbenchmarks? Microbenchmarks can be misleading, and there's no guarantee you're benchmarking the important things. It mentions profilers in passing, but i find it more productive to start with a profiler.

signa11 10y ago

but there is no such word as 'performant' ! wiktionary doesn't count :) note that efficiency and performance are _not_ the same thing. improving efficiency implies doing less work for the same end-goal. thus, when a program is 'efficient' then it is doing the minimum amount of work that the computation demands. or in other words, we have the best algorithm around for some kind of complexity argument for the task at hand. an algorithm which is efficient is not wasting anything. performance on the other hand, implies, how quickly the work that is to be done is actually done. basically performance improvement would allow you to do the same amount of work faster (in time). is the program at any given point in time (during its execution) doing maximal speed of work ? that doesn't seem to make much sense. infact, in practical terms, what is the 'maximal speed' of work ? <theoretical constructs like Bremermann's Limit doesn't count :)> programs can perform 'well enough', but that doesn't mean we are all done with it...

wodenokoto 10y ago
Performance us actually much,much broader than the speed at which a task is completed. The performance of a classifier can be anything from how fast it runs, to its F1 classification score.
- signa11 10y ago
  > The performance of a classifier can be anything from how fast it runs, to its F1 classification score. but classification performance would be the efficiency of a classifier algorithm right ? i.e. can i get better classifications / generalizations etc. in lesser time.
  - wodenokoto 10y ago
    Yes and no. It can be better in less time, it can also be just better or just faster (but worse) all depending on what is important. Classifier A gets F1 score of 0.93 on test set has a lower performance than classifier B, which gets an F1 score of 0.94, regardless of time. However, you can also say that classifier C, which only achieves an F1 score of 0.929 has better performance, since it is four times as fast.

cs702 10y ago

I would add another law: Code organized in small, easy-to-read chunks >> code organized in long, dense chunks.

xixi77 10y ago
I would even say code organized in small, easy-to-read chunks >> code organized in long, dense chunks >> code organized in lots of tiny, impossible to read (because calls go back and forth all over the place) chunks :)
- cs702 10y ago
  OMG, Yes!

daemonk 10y ago

From a data analysis perspective (which seems like some of her rules are related to), my number one rule that I always try to follow is to: work with the data, not with the tools. It can be really easy to go down the rabbit hole of messing about with the perfect tool for your analysis and end up with no results. Optimization is important so far as you need it. If I can launch a bunch of aws instances to get a single-run job done in an hour, then I'll throw hardware at the problem instead of worrying about my code. I care about the analysis results, not necessarily how performant my method is. If I'll need to run the analysis multiple times or I plan to publish it as a tool, then thats another story.

gwbas1c 10y ago
A common recurring theme in my career are horribly-performing applications because the original programmers worked with an ORM instead of the database. Database code isn't hard! An HBM file is just as complicated as handling a data reader! Stored procedures (or in-line SQL) are simpler in the long run!
- ansgri 10y ago
  I also don't get the ORM stuff: typically you work either (1) with lots of different objects organized in some kind of document (in NoSQL sense), and you want all these objects to be predictable, free from side effects and clearly serializable to e.g. JSON, or (2) with bulk data which you transform and aggregate to come with a small collection of fully constructed (also, denormalized) objects, and for this purpose SQL is beautiful. Or else they wouldn't've invented Linq to Collections.

tofflos 10y ago

I believe there should be a stronger distinction between decent performance and high performance. Most frameworks coupled with idiomatic code will give you decent performance. I find controlled experiments / microbenchmarks to be a useful method for finding the initial bottlenecks of a system. Once I know the initial bottlenecks I can make an informed descision on whether that performance is sufficient. Controlled experiments / microbenchmarks are also essential in establishing a ballpark number for the theoretical maximum performance of your system. From that point on, the performance is yours to lose.

catnaroek 10y ago

> It is critical that people question “how does this magic actually work?” No. It's critical that people question “why do I have to rely on magic?” in the first place. Even in high-level languages, perhaps especially in high-level languages, it's a good idea to write straightforward code. > there is an appalling lack of candy in the C/C++ ecosystem (...) performance isn’t hidden C and C++ are very different languages, and there is no shortage of C++ libraries full of incomprehensible magic. When debugging template-heavy C++ code, it can be very hard to determine where expensive and unnecessary object copies are created. Thank you C++, for making copy construction implicit! > Are you producing too much garbage unnecessarily? The high-level programmer's best defense against creating too much garbage is programming with values (whose redundant representations in memory can be automatically deduplicated by the runtime system) rather than object identities. > Are your dictionaries too big to the point of being inefficient? The problem isn't the dictionary abstraction, but rather the implementor's choice of underlying data structure. If you have a really big dictionary whose keys are strings (a common use case), you want tries, not hashtables. > string concats can be replaced by string builders in the same amount of lines, Using string builders is a low-level chore, and defeats the point to using a high-level language. A better alternative is using a persistent list/string data structure that actually supports efficient concatenation. > Does your program start ad-hoc threads? Use a threadpool with fixed size. Again, too low-level. A programmer working with a high-level language should be able to spawn as many green threads as she wants to, and let the language's runtime system handle multiplexing those green threads over OS threads. > Unless you are 100% sure the lines are always of reasonable size, do not use readline. This is terrible advice. If readline is causing you problems, you are using the wrong string data structure. --- Okay, I'm done bashing what could be bashed. The last two items in the OP are actually good.

perfmode 10y ago
> Again, too low-level. A programmer working with a high-level language should be able to spawn as many green threads as she wants to, and let the language's runtime system handle multiplexing those green threads over OS threads. Do this in Go and you'll be surprised how quickly you run out of memory.

overgard 10y ago

Rule #1 is bogus. If you're starting with a language that's 2-10x slower you're always going to be behind the curve. There's a reason C and fortran haven't gone anywhere.

OskarS 10y ago
You're not wrong, but in the real world it frequently happens that the choice of language is not the bottleneck. The bottlenecks are usually things like memory, network and file I/O, making the language you write in make very little difference.
- klodolph 10y ago
  Well... if memory is the bottleneck, and you use a language implementation where all the integers are heap-allocated, things are not looking good. I would say that choice of language can important if your bottlenecks are CPU, memory, or maximum latency.
squeaky-clean 10y ago
> If you're starting with a language that's 2-10x slower you're always going to be behind the curve. I got involved in a huge discussion about optimizing a web app recently. Things that were learned from the conversation? 1) It turns out moving more frequent cases to the top of an 'if-else' chain in JavaScript offers a greater speedup than I expected. 2) It doesn't matter if you shave 4ms off a request by optimizing your if-else chain if a little later in your code you make 27,000 database queries when you could have made 2. Knowing how to write a performant app will always be better than writing sloppy code in the fastest means possible.
- tomsmeding 10y ago
  27000 instead of 2 database queries would seem to be more than just a performance problem...
  - sokoloff 10y ago

gens 10y ago

gens's* law of writing software that performs well: Don't be smart. Do simple data structures where you can. Arrays, AoA, SoA, AoS. Process data in bulk where you can. Put complex algorithms only where needed (kd-tree when doing something like raytracing, threading only when necessary and even then only with bulk processing, complex locking or timing mechanisms only when you have to, etc.). Don't follow paradigms blindly. Basically data should be processed only in a functional way or in "waves". When there are only a handful of variables, a functional way will keep them in cpu registers. When there is more data, going over an array will make the cpu load the data that is to come next into the cache. Oh, and write C. [*] gens is a hobby programmer and possibly an idiot

marknadal 10y ago

Glad this submission is being upvoted but I think there is room for more practical and direct advice. Here are some resources for JS: - https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k... - https://github.com/amark/gun/wiki/100000-ops-sec-in-IE6-on-2GB-Atom-CPU https://github.com/amark/gun/wiki/100000-ops-sec-in-IE6-on-2... - http://danieltao.com/lazy.js/ http://danieltao.com/lazy.js/

adrianratnapala 10y ago

What is the difference between "performant" and "fast"? If we were talking about cars, then I would say performance includes not only speed but all kinds of things to do with handling. But in computing it always seems to mean "speed"[1], and "performant" always seems to be a bizarre neologism for "fast". I think people invented it because speed is a many faceted thing. There is latency, there is thoughput, there is user-visible responsiveness, all at multiple interacting levels. But these complexities and vaguenesses apply equally to the quasi-word "performant". [1] Actually the main article is a partial exception as she inconsistently includes stability within "performance". In one sentence she says "...performance degradation, including crashes, and the unbounded use of resources." But later she says "Code that doesn’t perform, or that crashes."

TickleSteve 10y ago
fast == absolute. performant == relative (efficient on the hardware available). e.g. an algorithm may be performant on a little Cortex-M but certainly is not fast compared to the same code on an I7.
- adrianratnapala 10y ago
  The problem with this definition is that it isn't true. 17km/hour is an absolute speed. It is fast for a runner, OK for a cyclist and slow for a car. "Fast" is relative.
  - TickleSteve 10y ago
    I agree in that context.... but in the context the original sentence was used, the statement stands. English is not the most precise language....

rahilb 10y ago

Forget _laws_, I just want to know how the dlang forum is so fast.

YZF 10y ago

- Programming language does matter. You will not be able to get the same performance in any programming language you choose. - Abstractions are the enemy of performance. You can't get high performance through many layers of abstraction. This relates to my previous point. - Algorithmic complexity matters when dealing with large data sets. Abstractions can hide the true complexity. (e.g. the famous string append example from IIRC Joel Spolsky). So the key to high performance software is: - As close as possible to the hardware. - The right data structures/layout (taking into account the hardware). - The right algorithms. - Measure properly and optimize.

sshumaker 10y ago
I think your point around abstractions could be more nuanced. The wrong abstractions can be deleterious to performance, thoughtfully chosen ones can actually be beneficial. Every programming language is several layers of abstraction above the hardware it runs on, which gives the compiler opportunities for optimization, or even the superscalar CPU opportunities for parallelization / reordering. And so on.
- YZF 10y ago
  I've yet to see a compiler that can beat a human hand-optimizing. It's true that for zero effort the compiler can usually do better but if you really care about performance you need to get around those abstractions. I worked on a wavelet video decoder, after a while we had a pretty optimized C code that used SSE intrinsics for large portions of the decode. Some clever guy spent 3 months and rewrote the entire decoder in assembly. It involved careful data layout and optimizing the instruction sequences. It ran more than twice as fast than our hand optimized C code. Same algorithm, input and output.
flukus 10y ago
I'd make that last key number 1.
taneq 10y ago
> Abstractions are the enemy of performance. You can't get high performance through many layers of abstraction. This relates to my previous point. This depends on the kind of abstraction. Layers and layers of crap will never be fast. The correct stack of abstractions, which map well to your problem space, will usually make your code faster because they will make it easier for you to see higher-level optimizations. > Algorithmic complexity matters when dealing with large data sets. Abstractions can hide the true complexity. (e.g. the famous string append example from IIRC Joel Spolsky). Very true. Abstractions are a tool to help understand the problem space, not an excuse to avoid understanding it. > Measure properly and optimize. A+. If you can't measure it, you can't control it. It boggles me how many people don't get this. "I replaced all the floating point math with integer math because integer math is faster." Really? IS IT? How do you KNOW? Did you benchmark it? "No but..." ahem sorry, I've had this argument too many times. :P

syngrog66 10y ago

related to this you may want to check out my cheatsheet PDF on software performance & scalability: http://synisma.neocities.org/perf_scale_cheatsheet.pdf http://synisma.neocities.org/perf_scale_cheatsheet.pdf welcome feedback and ideas for things to add or change

BigJeffeRonaldo 10y ago

Why do English-speaking computer people decide to take an English word like performing, add a random French ending, and use their weird word everywhere? Do they think think it sounds better? Programmers need to study more humanities and literature in school so they can learn what their languages sound like