Talk:Program optimization

message: I've done the assessment very quickly, the article still feels like having some issues. For instance, the "premature optimization" mantra has been added over and over without a global review, so the article needs a global restyling to fix this. --Blaisorblade (talk) 12:02, 7 January 2009 (UTC)
thread_title: Assessment

message: 'Software Optimization' redirects here. In the UK that would be spelt 'Software Optimisation', which currently does not redirect here. I don't know how to do it, but if we could have that redirect here too, that would be very handy, as I keep on landing on the search page, wondering what I've done wrong. 152.78.162.177 (talk) 14:39, 24 October 2011 (UTC)
replies: text: Have submitted a request for this 81.174.243.233 (talk) 23:36, 17 November 2011 (UTC)
replies: text:  Submission has been accepted. This issue is now closed. 81.174.243.233 (talk) 01:32, 18 November 2011 (UTC)
thread_title: Redirect : Software Optimisation

message: I dont know exactly what parts of the article are inspired by the cited source 'the art of programming'. I know of one book entitled like that, but it has no real focus on optimization. Instead, since D.E. Knuth is cited several times in this article, the real source may be his book, 'the art of computer programming'. Am I wrong ?
King Mike
: Fixed by somebody else. --Blaisorblade (talk) 01:12, 4 January 2009 (UTC)
thread_title:  Reference 'the art of programming' 

message: Improving about 20% of code is often responsible for 80% of the results
contradicts with
90% of the time is spent in 10% of the code, and only 10% of the time in the remaining 90% of the code
Sjord 17:59, 14 April 2006 (UTC)
replies: text: Strictly, I don't think they are talking about the same thing -- one's about writing the code and the other about rewriting it.  Still, I'd be happy to see both removed since they're essentially unverifiable. CRGreathouse 23:38, 19 July 2006 (UTC)
replies: text:  Since the statements are still there, even if they have been clarified, I'll answer by saying that this is a well-known rule of thumb among programmers. If anyone wants to challenge that, look for computer science literature about optimization or add  to that. About the seeming contradiction, the rule is stated with various rates (80-20, 90-10), because those are not exact rates. I think, however, that the first statement has been incorrectly inferred from "80% of the time is spent in 20% of the code", or something like that. I say "incorrectly inferred" because one cannot copy-n-paste ratios here, for instance because the remaining source code should not be optimized at all. --Blaisorblade (talk) 22:35, 3 January 2009 (UTC)
thread_title:  Contradiction 

message: in the article it says that python is a "very high level language". I would say very high level languages are 
Domain-specific_programming_languages (DSLs). IMHO Python is just a high-level language and it's definitely no DSL!
--Riedel 21:57, 19 July 2006 (UTC)
thread_title:  Very high-level language 

message: This article should also address hardware and energy aspects of efficiency and optimization.  But it does not currently address them at all, and has no links at all to any such info!-69.87.202.60 12:05, 17 May 2007 (UTC)
replies: text: Yes it should.  Please add them.  Derek farn 12:31, 17 May 2007 (UTC)
thread_title:  Energy efficiency 

message: The link 
* Article "A Plea for Lean Software" by Niklaus Wirth
refers to an article requiring paid subscription to read. WP:EL guidelines state:
"6. Links to sites that require payment or registration to view the relevant content."
should general be avoided. If the IEEE is hosting it, I expect it is a classic article. Nevertheless, it's not accessable without payment. Is it OK to remove the link?
Regards,  --Camacan 03:33, 26 July 2007 (UTC)
replies: text: Could we link to something like: http://cr.yp.to/bib/1995/wirth.pdf instead? Also, the current link does atleast point to an abstract, that's not all that bad.... --DFRussia 07:57, 18 August 2007 (UTC)
thread_title:  Should link to "A Plea For Lean Software" be removed? 

message: It appears to me that this topic starts out correctly -- talks about system optimization -- then goes right down into talking about optimizing pieces of code. But these are two separate beasts. The comments about premature optimization (by Knuth and others) focuses on optimizing pieces of code. But note -- many of these quotes are very old -- 30 years or so. And they are applicable to that domain (code optimization) but not to systems optimization which holistically cover the entire infrastructure. 
What do you think? SunSw0rd 17:58, 13 November 2007 (UTC)
thread_title:  System versus Program versus Code 

message: The section on interpreted languages is bullshit. Interpreters usually work in 3 phases: parsing the source into a series of tokens, parsing the tokens into a syntax tree, and then interpretation of the syntax tree. By far, the most computationally expensive is the last phase, because that's where the code is actually executed. Removing extraneous whitespace and comments only affects the first phase (the lexical analyzer), which is already extremely fast.
This section is really talking about size optimization over networks. This has nothing to do with interpreted languages. You see this for any form of data. For any data, whether it is source code, executables, or plain media, it is better to have smaller sizes so it takes less time to transfer over a network.
In conclusion, I suggest this section be removed, and possibly replaced with an obvious "data should be optimized for size to speed transfer over networks" statement.
--72.177.62.3 (talk) 22:58, 11 December 2007 (UTC)
thread_title:  interpreted languages 

message: The macros section seems inaccurate to me. First, the claim is made that C preprocessor macros are mainly limited to performing the same function as inline. I've seen this argument before, which has led people to largely condemn macros as inline is safer and more practical. In reality, C preprocessor macros are capable of many of the same things that Lisp-like macros or C++ templates are. This is because they do not merely expand to text limited to one pass but will also recursively expand all expansions. This allows macro names (or parametric parts of macro names) to be passed as macro parameters, and although the expansion is either very wide and specific or very general (as opposed to something mixed like what template specialization allows) it can be hierarchically arranged to minimalize the amount of redundant macros needed to allow for specialization. I've seen few people actually use CPP macros in this fashion but it can be done and it's quite powerful (and I regularly program with this technique).
Second, I don't understand what kind of claim is being made that "compiled code" is substituted in Lisp-like macro systems. Compiled code is neither modified nor inserted. Macro expansion is as much textual expansion as the CPP style is, it merely has more facilities for pattern matching, hygiene, self recursion, specialization, etc. It's certainly a much more powerful system however.
I'd appreciate it if some others who feel experienced with these topics could give their input. I feel that this entire section should be rewritten, although it might not really belong in this node to begin with.
Exophase (talk) 19:53, 8 February 2008 (UTC)
replies: text: Usage of C macros which cannot be replaced by inline is something I use regularly, but it does not matter for this article at all (even if you can use them for some optimizations, I don't see any notable pattern in that). I did rewrite the section - I knew both C macros and Scheme macros, and did some research on Lisp ones. I agree about Domain-Specific Languages through macros (never used them like that, but it's quite obvious that it's possible - after all, even libraries can be described as DSL). About "compiled code substituted" in Lisp systems, I hope I clarified the issue in the new text. --Blaisorblade (talk) 11:56, 7 January 2009 (UTC)

text: I agree too. It should probably go, if there's consensus. For now, I've fixed it to not be a subsection of "When to optimize"; thanks for pointing it out. Shreevatsa (talk) 13:47, 13 March 2009 (UTC)

text: I also agree that macro-use is purely code substitution and therefore may optimise software development time but does not improve the performance which is what this article is about.  — Preceding unsigned comment added by 141.228.106.150 (talk) 09:51, 11 October 2012 (UTC)
thread_title:  Macros 

message: "In some procedural languages, such as C and C++, macros are implemented using textual substitution, and so their benefit is mostly limited to avoiding function-call overhead."
Anyone that's read the inlining article on wikipedia would know that removing the function-call overhead is the -least- effect that inlining code has. Constant folding and dead code removal have a far greater impact. I'm not game to change it myself, as I don't know anything about functional programming languages. Themania (talk) 10:19, 5 April 2008 (UTC)
replies: text: I've changed the paragraph, the old text didn't make a lot of sense - I guess that was written by a Lisp programmer with limited knowledge of C/C++. Some details may need fixing though. --Blaisorblade (talk) 10:02, 5 January 2009 (UTC)
thread_title:  Dispute of sentence (about macros) 

message: "With modern optimizing compilers and the greater complexity of recent CPUs, it takes great skill to write code that is better than what the compiler can generate, and few projects need resort to this ultimate optimization step. Although a large amount of code written today is still compiled to run on the greatest percentage of machines. As a result, programmers and compilers don't always take advantage of the more efficient instructions provided by newer CPUs."
I have to disagree, in the case of streaming instructions and common assembler optimisations the only skills required are to be able to write assembler and to know of their existence. Its very easy to out do even the MS C++ compiler with some asm... my first foray into assembler programming was for just this purpose and was so easy that my horribly inefficient inline assembler was faster. Even simple stuff like the memcpy and memset packaged in the latest runtime libraries for MSVC++ can be easily optimised by using unrolled loops and the non-temporal copy instructions... Certainly nothing more skillful than just using the provided instructions as they were intended to be used.
Another classic example is that you have to specify the instruction set in the MSVC++ compiler, whereas it is easy (though time consuming) to write code that operates on all Intel CPUs utilising the SSE/SSE2 etc... instructions as appropriate.
I think its just that these technologies are still relatively new to the compiler and so the support is not yet full or powerful. I'm sure the compilers and libraries will catch up, but there will forever be new technologies available that will allow people with knowledge of them to outdo the compilers...
Of course this only applies to a small set of optimisations, its certainly not easy in all cases... but in many cases where you want to do it it is.
I find it disappointing that assembly programming is labelled as "something hard that you probably don't need", when really its easy and useful... particularly when you run out of optimisations to do... you may even find that optimising memcpy or memset will provide a signifcant boost (in a ~512x512 software triangle renderer used in Winamp AVS the speed gain from zeroing memory with assembler was about 3-4fps, from 27fps up to about 30fps).
I'm going to edit this statement to remove the "great skill" part, it seems out of place even once I ignore my personal feelings on the matter... "it is most often diffcult" is better imo...  —Preceding unsigned comment added by 194.168.3.18 (talk) 15:28, 25 March 2008 (UTC)
replies: text: "You have to specify the instruction set in the MSVC++ compiler" doesn't count, obviously, as assembly programming. Then, you say you can outdo "even the MS C++ compiler"... I'm a GCC user, but the only really good optimizing compiler I know of is the Intel compiler ICC (but GCC, for some reason, used time ago to often outperform it on integer programming - I hope they fixed ICC). Finally, loop unrolling is not without disadvantages, so most users should just rely on libraries (and have good ones). I'm surprised compilers can't handle this. The current text is anyway OK, so let's mark this as . --Blaisorblade (talk) 11:49, 7 January 2009 (UTC)
thread_title:  assembler optimisation requires "great skill" 

message: I might have missed it in the "unbulleted lists" presented at the end of this article, but a discussion of AST-based optimizations seems to be conspicuous in its absence.  There are other forms of "optimization" in computer science that don't necessarily center on code rewriting and rearrangement; caching comes to mind. SqlPac (talk) 03:01, 19 September 2008 (UTC)
thread_title:  Abstract Syntax Trees? 

message: Use of multi-core processors, multiple threads and other concurrent processing techniques have been totally omitted from this article. (I added a reference on the list). But really in this age it is one of the key techniques to optimising software with regards to time. (Even on a single-core processor, using multiple threads will often be faster as the operating system is often able to slice up the processor time more optimally).  — Preceding unsigned comment added by 141.228.106.150 (talk) 09:56, 11 October 2012 (UTC)
thread_title:  Concurrent Programming 

message: I have a comment on the Trade-offs section. It don't doubt that there is an optimal trade-off curve between, for example, time and memory usage in an algorithm. However, the reader should be given to understand that very few programs (as opposed to theoretical algorithms) are actually on that curve. In my experience, many programs can be improved in both time and memory usage, and thus be brought closer to the curve. MikeDunlavey (talk) 15:50, 8 November 2008 (UTC)
replies: text: Makes sense. You should add that. Are you still there @MikeDunlavey? ... 16 years later Stevebroshar (talk) 14:12, 20 May 2024 (UTC)
thread_title:  Trade-offs 

message: This is what 99% of the article is discussing. Attempting to generalize this to XXX optimization in computer science, e.d. disk defragmentation, IP route optimization (google this, since we don't seem to have an article) or even various forms of hardware optimization, e.g. VLSI optimization is hopelessly broad. Pcap ping 18:11, 1 September 2009 (UTC)
replies: text: What did it used to be called? I don't know if it's possible to determine the old name after a rename :( ... IMO it should be Optimization (computer program) since program optimization isn't a real term; it's made up for WP; it's a notable-topic-with-an-adjective-in-front (NTWAAIF). Stevebroshar (talk) 03:42, 20 May 2024 (UTC)
thread_title:  Renamed this article to program optimization 

message: I suggest changing the name further to "code improvement". The term 'optimize' is such a misnomer since it is sometimes used in an exact sense in mathematics and information theory. When we try to make code faster, we can rarely say for sure there isn't an even better way to do the same thing. 188.126.200.132 (talk) 04:34, 20 July 2014 (UTC)
replies: text: no. That is WWWWAAAAYYYY too broad. And improving code often connotes increasing readability whereas optimization often goes the other way. Stevebroshar (talk) 03:44, 20 May 2024 (UTC)
thread_title:  Rename to code improvement 

message: I remember a quote to the effect of: The only appropriate optimization is when you've measured the speed and it is too slow (for whatever purpose it's being used for). Where is that quote from? Could it be worked into this page? It seems extremely relevant.
Also consider that the speed of computers is always increasing (ref. Moore's Law), and the ability of humans to comprehend software code only decreases over time due to various factors. Therefore we should not optimize for computer speed, our time would be better off spent optimizing for human understanding. — Preceding unsigned
:Premature optimization is not good. But, if it needs to be faster ... it needs to be optimized. ... Are you saying it's bad to optimize, ever? That's nonsense. Stevebroshar (talk) 03:37, 20 May 2024 (UTC)
thread_title:  When (not) to optimize 

message: The article starts with the goals of optimization.
One goal is missing up to now: readability/maintainability.
If you compare this to cars: Most people tune their car to be faster,
but cars can be tuned to look nicer or to increase convenience  — Preceding unsigned comment added by Guettli (talk • contribs) 14:48, 9 January 2019 (UTC)
replies: text: I don't think tuning a car to look nice is a thing, no. I wash mine :) An engine can be tuned ... even for performance and in that sense it's being optimized. So, I think tune and optimize overlap, but are different. ... but why are you talking about tuning? ... Optimization often results in less readability and less maintainability. And that's OK since readability/maintainability are _not_ goals of optimization. Stevebroshar (talk) 03:32, 20 May 2024 (UTC)
thread_title:  Goal of optimization