1. Yes, you should consider the performance of your programs as you design them. Indeed, there is an entire hierarchy of performance considerations to observer, starting with the choice of data representation, the operations on it, amortized vs worst-case scenarios, distribution of operations on the data, persistent vs imperative data, choice of functions vs methods, granularity of modules, classes, functions/methods (in-lining vs separate definitions), and so on.
2. I don't think micro-level optimizations is unpopular only here. It has to be unpopular in any discussion until you have exhausted all levels above micro-optimizations, especially in a language such as Racket where it is easy nay trivial, to switch from second to cadr [in-lined] and such. 3. Don't confused "unpopular" with "unfriendly." This list is welcoming and it is okay to discuss off-topic ideas to some extent. You will get good and honest answers. -- Matthias On Apr 7, 2015, at 3:31 AM, Giuseppe Luca Scrofani <glsdes...@gmail.com> wrote: > When, some day I will be, maybe, capable of really understand all of what you > told me, I will dismiss my questions like this by myself and be proud of it. > I see that micro optimization it is not a popular theme here, but my > question, which I think is more general (as badly expressed maybe) don't > seems to me so unreasonable. > Personally I don't see too much evil in keeping in mind performances down to > the line level: > > (if (and (intensive-calculation-procedure) (fast-executing-procedure)) > x > y) > > Can be easily changed in > > (if (and (fast-executing-procedure) (intensive-calculation-procedure)) > x > y) > > to save potentially a lot of time sometimes, virtually. > > Asking to use regexp to extract data from xml strings result invariably in > "you dont want to do that" (even when it is faster/easier to effectively do > that). > I see why expert developer answer like this. But one can learn and make > experience also by doing fervently stupid things. > > Thanks all for the discussion, especially to Vincent for pointing me to some > useful resources. > > Lux > >> I know micro optimization is bad and not needed in the great majority of >> cases, but what if: >> >> - I want to because I am OCD :D > > Get help :-) > > Seriously ... I do understand because I spent a decade doing HRT vision > systems for industrial QC. But you need to wring as much as possible out of > your algorithms and data structures *before* worrying about micro > optimization. > > If you're accessing a list billions of times, you're in trouble before you > begin. > > >> - I really need it for (in theory) a database server, > > My master degree is in database technologies ... trust me, you don't need it. > Either you are implementing ACID which is limited by the speed of stable > storage (SSD still is slower than RAM) and where speed depends on minimizing > data access, or you are implementing key-store which runs entirely out of RAM > and where speed depends on ... wait for it ... minimizing data access. > > >> or a last generation video game, or maybe a voice recognition software (all >> computation intensive applications) when I can not optimize my algorithms >> further, and before resorting to assembler? > > Few games need more than SRT and most games can be written with any decent > HLL having access to SIMD array processing. I suspect the same of the signal > processing for voice recognition but I'll defer to > > I don't know offhand whether Racket uses SIMD for array processing (where > available) - it does have typed vectors/arrays which allow operations without > runtime type checks. If it doesn't already use SIMD, there's no reason it > couldn't. > > On modern x86 the SSE units generally are used for floating point in > preference to the x87 FPU , but that is independent of array processing and > simply due to the fact that the SSE units tend to be easier to work with > (registers vs stack). The only real reason to use the x87 is for extended > precision, or for a trig operation that [model dependent] doesn't have an SSE > implementation. > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
