|
Re: Module Efficiency
by Ovid (Cardinal) on Apr 10, 2003 at 18:16 UTC
|
It's more important to worry about correctness than efficiency. Read Premature optimization for more explanation about this.
I've found that developers who constantly worry about whether or not something is fast enough tend to keep tweaking rather than developing. That's a bad thing. Once you get it working properly, you may very well discover that your application is fine. Remember: if it's fast enough for the customer, it's fast enough.
That's not to say you should never worry about performance up front. If you have a known systemic performance issue (manipulating 3-D graphics, for example), then this is appropriate to consider. Otherwise, pretend that speed's not important until you're close to finishing the app and you have a better opportunity to find out what, if anything, is really causing performance issues.
Cheers,
Ovid
New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)
| [reply] |
|
|
| [reply] |
|
|
Do you care to justify that with a some facts? I'd rather have a correct program that's slow than an incorrect program that's fast.
Coplan didn't say "this subroutine is slowing my program down". The question that Coplan was asking was a general question about efficiency. That's focusing on how fast the tires are turning and ignoring that you're about to crash. If, instead, I focus on whether or not my system is properly organized with minimal duplication of code and written in a clear, easy to read manner, then I can focus on what might be truly affecting my performance. Trying to improve the performance of a nested loop that ultimately only uses a half percent of the runtime is probably a poor utilization of resources. That is the real inefficiency.
Cheers,
Ovid
New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)
| [reply] |
|
|
|
|
|
Re: Module Efficiency
by MrCromeDome (Deacon) on Apr 10, 2003 at 18:28 UTC
|
This isn't so much about efficiency as it is about writing your module, but when you are ready, check out tachyon's Simple Module Tutorial. It's an excellent resource for getting started with modules. A nice module template is provided, as well as some wonderful explanation of what it all means.
Hope this helps,
MrCromeDome | [reply] |
Re: Module Efficiency (same)
by tye (Sage) on Apr 10, 2003 at 18:46 UTC
|
Putting code into a module doesn't have any real impact on how much memory/CPU it uses.
I have a couple special scripts that I use quite a bit. I include them as needed
What you do mean when you say that you "include" a "script"? Not that I think knowing the answers to these questions will lead to revelations about big efficiency differences. And worrying about efficiency before you've noticed a real problem with lack of efficiency is usually wasted effort (or worse).
- tye
| [reply] |
Re: Module Efficiency
by marinersk (Priest) on Apr 10, 2003 at 20:11 UTC
|
Ah, yes, "efficiency". The term's too broadly used here:
- There is the efficiency of your time as the coder. Will you reuse this code? Will it be faster for you to reuse it when it's in a module rather than finding another script that uses it and then cutting and pasting it? What if you need to upgrade the way the function does its work? Fix a bug/improve performance/increase functionality/etc. Will it be faster on your coding time to modify it in one place or go hunting for everyplace you've used it and fix them all?
- There is the efficiency of the time of others who use or maintain your code in the future. Same questions as #1, except without your preconceptions of how well you will be able to do these things, being familiar with how and where you did it the first time.
- There is the efficiency of the code at runtime. But do we mean efficiency of space (disk, memory, etc.) or do we mean efficiency of time (runtime)? And if we're talking about efficiency of execution speed, are we talking about a process that is run daily and takes 2 hours and we're looking to save 15 minutes, or are we looking at a process that will be run repeatedly throughout most days, takes 4 seconds to complete and we're looking to shave it down to 3? Honestly, how much savings are you expecting with the argument of "inline" vs. "module", and how much does that savings actually matter?
Context is everything, my friend. And in my experience, most things done in Perl aren't done with execution-efficiency overwhelmingly in mind. It is development efficiency that is of concern, as a rule, with a heavily intrusive emphasis on source-size efficiency (Using a regular expression that takes 5 minutes to create and adjust rather than 5 lines of index() and substr() code that take 30 seconds to write, for example).
I'm not saying it's a bad question to ask. I'm pointing out that, in my experience, in Perl, it's mostly academic and not particulary of practical concern.
Does it take longer to open a second file and read a few redundant lines out of that file than it would to open only one script file and read everything in one slurp? Probably. Does it actually have much of an impact on the interpretation/compilation phase? Probably not. Will it affect the execution speed? Maybe. Will it make enough of a difference to notice? Probably not.
My two cents.
Regarding the running theme of your question, however, I concur wholeheartedly -- knowing how to make and use a Perl module is a useful skill, and if you have an opportunity to learn it and pass on it, you are depriving yourself of a Perl tool for future use.
Just remember the 1;
:-)
| [reply] |
Re: Module Efficiency
by perrin (Chancellor) on Apr 10, 2003 at 19:56 UTC
|
The main reason to use a module instead of just including a "lib.pl" with require, is to avoid polluting your namespace with the functions and variables from lib.pl. When you require a lib.pl script with no package name, all of its subs go into the main:: namespace, possibly overwriting things from your main script. It's also easier to understand where a sub is defined if it is called as "MyModule::foo()" instead of just "foo()" when there is no sub called foo in the main script. | [reply] |
Re: Module Efficiency
by gmpassos (Priest) on Apr 10, 2003 at 20:54 UTC
|
What is more efficient, PM or scripts?
A: Depends!
The primary objective of a PM is to make a module/class that can be reused easy/fast in many different ways, with different applications. And a script is made just to work in some situation.
But is possible to make a PM that works fast too, you just need to make a good work. The advantage of the module is to make it in a architecture better than scripts, since you project it to be used in many ways. The best way to make reusable codes is with Object-Oriented Classes, take a look at perlmodlib, that enable the multi use of your code, since you can make each object of your PM independent of the other.
About speed improvement, you will read a lot of peoples saying that OO is slower, since paste the object reference is slower than normal variables. But in the end you will see that speed is really lost in point that are runned a lot, specially loops, in your code, or when you are working with the memory/HD, and not in the OO point. The best way to make a fast code is to know what hapens in the interpreter and try to use better ways, but never forget the maintenance of your code!
Soo, here are some nodes about speed improvement:
- How Perl Optimize your code & some code TIPS ;-P
- Memory usage and perl
And don't forget:
- www.perldoc.com
But first you need to learn how to write nice PM, and than spend time with deep speed improvement. One good tip is to always use strict in the top of your code, at least for variables. And in the end you can use XS, that can bring another world for you, not only fast codes in C. ;-P
Graciliano M. P.
"The creativity is the expression of the liberty". | [reply] |
Re: Module Efficiency
by Tomte (Priest) on Apr 10, 2003 at 19:54 UTC
|
I include them as needed, and I never seem to have problems.
I read this as require 'myscript.pl';
It's a small but important step to change this to use myscript, IMHO, as it clarifies the meaning and just makes your actual used-as-a-module script a real perl-module (following the tips and links given to you already).
If I misread this, and including means cut & paste, let not speed, memory, efficiency of the code and such be your first concern, but maintainabilty: turn your code into a module / modules for the sanity of those following you or accompaning you in your coding projects, again by following the tips and links given to you allready.
kind regards,
tomte
Hlade's Law:
If you have a difficult task, give it to a lazy person --
they will find an easier way to do it.
| [reply] |
|
|
Your assumption was right. I don't copy/paste, as that gets annoying for me. What I'll do is stick a copy of the "common.pl" script (as I call it), and then I'll include/require it at the beginning of my program.
I do this mostly with web interfaces that I do. A lot of the scripts are generic SQL queries, cookies, forms, and so on. Honestly, they could easily be placed into a module.
As Ovid pointed out, and I agree, it would be best to make sure the script works perfectly first. The script that I'm currently working on is smooth, and very usable. I'm right now in the process of optimizing my code, and cleaning it up a bit. My reason for asking my initial question was to see if I could improve speed and (more importantly) memory usage with the script.
All your feedback is great. I'm gaining new perspective. Thanks all!
--Coplan
| [reply] |