CGI/Perl Guide | Learning Center | Forums | Advertise | Login
Site Search: in

  Main Index MAIN
INDEX
Search Posts SEARCH
POSTS
Who's Online WHO'S
ONLINE
Log in LOG
IN

Home: Perl Programming Help: Intermediate:
Speeding up OO

 



yapp
User

Jun 18, 2002, 3:16 AM

Post #1 of 12 (1468 views)
Speeding up OO Can't Post

Hi there...

I wonder how I can speed up my OO (object orientated) code...

It seams to be slower, because there is more code to load. Off course, I want to use OO, because it's nicer for larger cgi programs. It's also more flexible for other people to add extra mods, etc...

But, how can I reduse the slow down of the code? Is the method calling really slower (because of a extra subroutine-jump) or is my program slower, because Perl needs to load more code at startup?

I run a benchmark in Perl from the BEGIN to the END block, using the Benchmark module off course..

Can anyone clear this up for me??

Yet Another Perl Programmer

_________________________________
~~> [url=http://www.codingdomain.com]www.codingdomain.com <~~
More then 3500 X-Forum [url=http://www.codingdomain.com/cgi-perl/downloads/x-forum]Downloads! Cool


fox
Novice

Jul 1, 2002, 10:47 PM

Post #2 of 12 (1447 views)
Re: [yapp] Speeding up OO [In reply to] Can't Post

Hey Yapp,

I've found that loading your subs right off helps the speed. If you move your sub routines to the top of your code I think you'll find it actually is faster. By how much it will improve depends on the complexity of your code.

I was writing search engines about 3 years ago when I was given the very same tip, it worked much faster through cgi. I've been doing it ever since. If I remember correctly loading the subroutines before your calls saves the interpreter from having to go to the bottom of your file before finding the definitions to your sub calls.

That's of course if you already weren't doing that. lol


davorg
Thaumaturge / Moderator

Jul 2, 2002, 1:32 AM

Post #3 of 12 (1445 views)
Re: [yapp] Speeding up OO [In reply to] Can't Post

Subroutine calls in Perl are generally an expensive operation. This is particularly bad in OO Perl as Perl can't know which subroutine to call until runtime as it needs to know the type of the object before it can know where to look for the subroutine.

If you're writing something where speed is that critical to you, then OO Perl may well not be your best choice.

--
Dave Cross, Perl Hacker, Trainer and Writer
http://www.dave.org.uk/
Get more help at Perl Monks


yapp
User

Jul 2, 2002, 3:19 PM

Post #4 of 12 (1443 views)
Re: [fox] Speeding up OO [In reply to] Can't Post

Well, since I work with objects, every piece of code is located in some module, use-ed first before any calls are made.

As for dave's reply: I was affraid for something like this. However, I don't think I really have a choice. Using the Exportor (or a own version) pollutes the name space of classes, in fact, creating more methods...

Using OO is flexible, and usable from other programs. It's easy to create more code that uses the functions (first reason), and I could call the functions from other programs aswell Smile That's my second reason for using OO.

Thank you both for posting your thoughts. It gives me something to keep in mind when working on the rest of my code.

Yet Another Perl Programmer

_________________________________
~~> [url=http://www.codingdomain.com]www.codingdomain.com <~~
More then 3500 X-Forum [url=http://www.codingdomain.com/cgi-perl/downloads/x-forum]Downloads! Cool


Revelation
Novice

Jul 6, 2002, 7:53 PM

Post #5 of 12 (1430 views)
Re: [yapp] Speeding up OO [In reply to] Can't Post

Personally, my belief is that if you can't use OO code, because of speed, it would be pertinant to invest some time into making your code comply to Apache::* (Perlrun takes hardly anything....) The speed increase of loading those modules into HTTPD will be great enough to allow you not to worry about loosing performance to OO.


yapp
User

Jul 7, 2002, 2:27 AM

Post #6 of 12 (1428 views)
Re: [Revelation] Speeding up OO [In reply to] Can't Post


In Reply To
Personally, my belief is that if you can't use OO code, because of speed

That's not the reason I use it. I want to have clean modular code, that I (or someone else) can use directly into another program. For example with my forum, it would be possible to display a who's online or recently posted page inside other pages.

I knew OO would be slower, so I posted this topic..maybe someone has soem hints on speeding up Unsure


In Reply To
it would be pertinant to invest some time into making your code comply to Apache::* (Perlrun takes hardly anything....) The speed increase of loading those modules into HTTPD will be great enough to allow you not to worry about loosing performance to OO.

mod_perl Smile if I could make my program capable for running at mod_perl, it would definitely speed up.. This is also something I'm considering.. at least, I've kept it in mind for a long time. With such rewrite, it's also easier to create code that fits mod_perl

Yet Another Perl Programmer

_________________________________
~~> [url=http://www.codingdomain.com]www.codingdomain.com <~~
More then 3500 X-Forum [url=http://www.codingdomain.com/cgi-perl/downloads/x-forum]Downloads! Cool


Revelation
Novice

Jul 7, 2002, 12:18 PM

Post #7 of 12 (1426 views)
Re: [yapp] Speeding up OO [In reply to] Can't Post

You may want to follow Tachyon's CGI::Simple, if you're not coding a mod_perl script, and use a __DATA__ token, and self-loader. This *does not* work under mod_perl.

use SelfLoader;
__DATA__
sub {} # Load on use.

Of course, this is best for larger modules, and I would recomend putting major subs such as 'new', and other subs used a lot, above the data token.
Or: If you have a load of subs just assigning values, to look into your own AUTOLOAD sub, that will allow value assignment, and create subs on demand.


yapp
User

Jul 8, 2002, 2:07 PM

Post #8 of 12 (1423 views)
Re: [Revelation] Speeding up OO [In reply to] Can't Post

Thank you for your suggestion Smile

I'll keep this in mind, although I can't use it in my current application.
Those modules are too small, and all functionality is used duing execution.

Some files are large, since they cover a big function, like reading a record. Others are small, because their methods only return what my central record-reader has done. They only have to function as interface; returning the data read.


Does __DATA__ and __END__ really not work with mod_perl ??? I mean, each one of my modules ends with:


Code
 
1;

__END__

=head1 NAME

....


So Perl doesn't need to read through the pod / perldoc.

Yet Another Perl Programmer

_________________________________
~~> [url=http://www.codingdomain.com]www.codingdomain.com <~~
More then 3500 X-Forum [url=http://www.codingdomain.com/cgi-perl/downloads/x-forum]Downloads! Cool


Revelation
Novice

Jul 8, 2002, 3:05 PM

Post #9 of 12 (1422 views)
Re: [yapp] Speeding up OO [In reply to] Can't Post

They don't work in mod_perl, because of the explenation here:

http://perl.apache.org/guide/porting.html#_END_and_DATA_tokens

On the other hand, you can use it with Apache::Perlrun (methinks), so it depend on how you're running your mod_perl scripts.


Paul
Enthusiast

Jul 15, 2002, 5:29 PM

Post #10 of 12 (1412 views)
Re: [Revelation] Speeding up OO [In reply to] Can't Post

I have written a 1.7MB perl script with about 320 files and all my major modules contain __END__ and pod underneath and it works fine under mod_perl


Revelation
Novice

Jul 15, 2002, 7:50 PM

Post #11 of 12 (1410 views)
Re: [RedRum] Speeding up OO [In reply to] Can't Post

Paul, I don't know what to say... but I have to wonder whether you're using Apache::Registry...?



This is documented on perl.apache.org, so I have a feeling it's true... if not, maybe you should email the fellows there...?


Paul
Enthusiast

Jul 16, 2002, 2:48 AM

Post #12 of 12 (1409 views)
Re: [Revelation] Speeding up OO [In reply to] Can't Post

>>
but I have to wonder whether you're using Apache::Registry...?
<<

<Location /cgi-bin/desk>
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options +ExecCGI
</Location>

 
 


Search for (options) Powered by Gossamer Forum v.1.2.0

Web Applications & Managed Hosting Powered by Gossamer Threads
Visit our Mailing List Archives