I would like to bounce an idea off the Xojo forum administrators, and the Xojo community as a whole.
What about adding a channel named “Optimize”, that is dedicated to questions and answers with regards to Xojo specific code optimizations. I know I’ve learned a lot by reading through optimization discussions in other conversations on this forum. Having a channel dedicated to optimizing code could be a great source of information on how to write better Xojo code.
Anyone else who think they might find such a channel useful?
I always enjoy reading the threads that focus on optimisation even though I am not able to offer much in the way of advice.
I’m already amazed at how fast my code runs and I’m a fairly novice programmer so would be interested in offering up some code snippets to let the guru’s get their hands dirty!
The only drawback I see is that some people will obsess over optimization too early in the process. Premature optimization is bad because you’re focusing on the wrong thing at the wrong time. Get it working and THEN worry about speeding it up.
[quote=135299:@Bob Keeney]The only drawback I see is that some people will obsess over optimization too early in the process. Premature optimization is bad because you’re focusing on the wrong thing at the wrong time. Get it working and THEN worry about speeding it up.
Just my 2 cents worth.[/quote]
The only problem with getting it working is that I’d then actually have to release the software.
Well, maybe not waiting until after the first release but perhaps beta testing to identify where the bottlenecks are and fix the big ones before release. Depends on how slow it is. Sometimes you can’t release it to the client/public without some basic optimization.
Optimization is indeed a fascinating topic. But I see a difficulty in having a dedicated channel. To start with, optimization is often tied to the platform. For instance, Windows requires optimization to alleviate flickering that is not necessary with Mac. And As discussed not long ago about getting the version number in Mac, there are several approaches, from AppleScript and Gestalt to Declare. All deeply tied to the platform. And in that, is a declare really an optimization, or should optimization be discussed within pure Xojo code ?
Then the framework counts. Optimization techniques valid in Desktop may not necessarily work in Web Edition.
I agree on the topic in creating an own channel for that… sometimes it makes fun to deal with an algorithm. just thinking about the Comanche code a couple of months ago…
[quote=135299:@Bob Keeney]The only drawback I see is that some people will obsess over optimization too early in the process. Premature optimization is bad because you’re focusing on the wrong thing at the wrong time. Get it working and THEN worry about speeding it up.
Just my 2 cents worth.[/quote]
[quote=135345:@Michel Bujardet]Optimization is indeed a fascinating topic. But I see a difficulty in having a dedicated channel. To start with, optimization is often tied to the platform. For instance, Windows requires optimization to alleviate flickering that is not necessary with Mac. And As discussed not long ago about getting the version number in Mac, there are several approaches, from AppleScript and Gestalt to Declare. All deeply tied to the platform. And in that, is a declare really an optimization, or should optimization be discussed within pure Xojo code ?
Then the framework counts. Optimization techniques valid in Desktop may not necessarily work in Web Edition.[/quote]
Optimization is probably a science (art) in its own right, and when done at the wrong time in the project cycle could jeopardize the release timeline of a project.
Given this, the positive side of optimization is that once you’ve learned about a better (more optimized) way to do something, the benefit of this new knowledge is usually seen in future projects.
Currently there is loads of great optimization tips from very experienced developers scattered across the forum. I’m just thinking that consolidating these intellectual contributions into a single channel could prove to be very valuable to any developer who is serious about sharpening his/her Xojo skills.
Certainly once you have the right algorithm implementing it optimally can yield additional benefits.
But, in general getting to “the right algorithm” is the initial problem and one that leads to sub optimal results.
Searching is an excellent example.
A dead simple linear search works but isn’t optimal in a lot of cases.
Variations on binary searches etc can yield great speed ups.
But, a hash, like a dictionary, may be even faster and, if its suitable, a great replacement. BUT if your focused on “searching” and always think in those terms a HASH might never come to mind.
DB queries are another common one where frequently you see people nest queries when a better answer is to write one slightly more complex query yields huge performance gains.
Hence why I’d say getting to the right algorithm has perhaps the most impact & implementation details can yield incremental benefits
It’s important to document in your code that you did it this way for performance reasons and that it may be necessary to revisit those characteristics in the future.
// This code is weird because X is faster than Y at this time.
// Be sure to test these assumptions in the future.
Donald Knuth’s famous advice conveys the message well that “premature” optimization is something to be avoided.
“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.” - Donald Knuth
So I guess it goes without saying Norman, that a solid understanding about algorithms is probably more valuable in the long run than a solid understanding of optimization.
Those opportunities in the critical 3% sure is an interesting field in computer science though…
[quote=135367:@Tim Hare]It’s important to document in your code that you did it this way for performance reasons and that it may be necessary to revisit those characteristics in the future.
[/quote]
This is why I would like to have some kind of tags or labels to add to Navigator items. A visible overview on the status of methods (like “beta” / “untested” / “verified” or something would allow much faster overview, I think.
But anyway, the best way to avoid optimizations is to never visit this forum and never watch a webinar. I restarted my first app I began last fall for the third time now because I learnt so much here that I couldn’t stand looking at the code, though working and the structure was that unorganized redoing seems easier than optimizing.