Think about Loose Coupling | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
The real trick isn't optimizing your code but optimizing your solution.
this is a good paraphrase of my answer... hell yeah, i optimize my code... but it's the data bottlenecks i optimize, not the millisecond differences you'd only get by porting to C. when all i get is milliseconds, i purely write for readability/security/correctness, not speed. i try to understand what my database does to retrieve/store data, so the requests i make of it can use indices, not full searches. i try to dump the results of a query into a perl hash if i reuse it, to avoid requerying. i try to keep the data ordered in such a way as to avoid the actual data structure causing problems, etc. i find that for what i want to do one or both of {perl, mysql} always has the data structure i want (in terms of efficiency of search, add, delete), so i can almost always avoid doing the hard work.. that makes for efficiency of development on several levels. by knowing perl/mysql i have an easy answer to all my data structure problems, i just have to use the struct, not build one first. and it is readable by others simply by virtue of being standardized (ie SQL 92) second, if there is an error in the data structure, the easy to fix ones are my fault (i used the struct wrong), and the hard ones are someone elses. if i'm using say, some feature new to mysql 4.0.0alpha and it breaks, we just add it to the bug list and wait for 4.0.1 -- the fix is free, i or my employer don't have to pay for me to debug, rewrite, debug, etc... if i were the guy writting mysql it would be a different story, but it's not like they write it in perl either... In reply to Re: Re: Optimizing existing Perl code (in practise)
by Xanatax
|
|