Benchmarking the Efficiency of Your Tools
•Download as ODP, PDF•
1 like•334 views
The document discusses benchmarking and optimizing Perl code. It provides an overview of common tools for profiling Perl programs, such as Benchmark.pm, Devel::SmallProf and Devel::NYTProf. It outlines factors to consider before and after benchmarking like memory usage, CPU usage and deployment environment. Examples are given demonstrating how using modules or custom functions can improve performance compared to plain Perl code. The document stresses the importance of understanding profiling data in the context of the full system before performing optimizations.
![AGENDA
,[object Object],](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Benchmarking the Efficiency of Your Tools
Similar to Benchmarking the Efficiency of Your Tools (20)
More from Marian Marinov
More from Marian Marinov (20)
Recently uploaded
Recently uploaded (20)
Benchmarking the Efficiency of Your Tools
- 1. 1H.com 1H.com Benchmarking the Efficiency of Your Tools Marian Marinov - mm@1h.com Co-founder & CEO of 1H Ltd.
- 3. $ $$ $$$ $$ $ If you rate my survey, I'll hook you up with $20 cPCache $$$. Go to this address to take the survey: http://go.cpanel.net/b11 and come up to the podium once you've completed it.
- 6. Before benchmarking @INC: /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 ................
- 11. file-bench-module.pl #!/usr/bin/perl use strict; use warnings; use File::Util; my $dir = '/home/hackman/bench-tests'; my $f = File::Util->new(); foreach my $obj ($f->list_dir($dir)) { print "$obj"; }
- 12. file-bench-plain.pl #!/usr/bin/perl use warnings; use strict; my $dir = '/home/hackman/bench-tests'; opendir B, $dir; while (my $obj = readdir(B)) { print "$obj"; } closedir B;
- 13. file-bench-sub.pl #!/usr/bin/perl use warnings; use strict; my $dir = '/home/hackman/bench-tests'; sub check_dir { my $dir = shift; opendir B, $dir; while (my $obj = readdir(B)) { print "$obj"; } closedir B; } check_dir($dir);
- 18. A module load times $ perl -d:Dependencies -MFile::Util -e 0 Devel::Dependencies finds 10 dependencies: /usr/lib/perl5/site_perl/5.8.8/auto/File/Util/autosplit.ix AutoLoader.pm Class/OOorNO.pm Exporter/Heavy.pm Fcntl.pm File/Util.pm XSLoader.pm constant.pm vars.pm warnings/register.pm No DB::DB routine defined at -e line 1.
Editor's Notes
- \n \n \n \n \n \n
- \n \n \n \n This talk was inspired by a talk from Tim Bunce who wrote the NYTProf \n \n I want to share with you, the things I haven't seen in other presentations on the subject. \n \n \n
- \n \n \n \n \n
- \n \n \n \n For me the most important tools are time, Devel::NYTProf and Devel::Dependencies \n \n \n
- \n \n \n \n \n
- \n \n \n \n \n
- \n \n \n \n \n The interpreter has different compile options which makes it load slower or faster. Linking to more or less libraries. \n \n So this talk is mainly about how to identify what is important \n \n \n \n \n
- \n \n \n \n \n Shared resources: \n \n \n \n \n shared memory \n \n \n locks \n \n \n files \n \n \n databases \n \n \n \n \n \n \n
- \n \n \n \n \n I/O usage is one of the most misleading factor because on live environments the I/O profile is completely different then on the development and testing systems \n Deployment environment – \n how often the app is executed \n what data it handles \n what is the average load of the machines without running our app \n \n \n \n
- \n \n \n \n \n What most ppl forget about this is that the number of executions is not the same and most time they don't take this into account. \n \n \n
- \n \n \n \n \n
- \n \n \n \n \n
- \n \n \n \n \n
- \n \n \n \n Most of the ppl will fail to understand the meaning of REALTIME. It is the SUM of USERTIME, SYSTIME and the time it had to wait for other processes to be executed or wait for resources. \n \n Note the difference between the results on beast and on the vm which is running on beast. \n \n \n
- \n \n \n \n Note here how there is almost no difference between the beast and its VM here \n \n Different filesystems affect the performance in different ways. \n \n \n
- \n \n \n \n \n \n
- \n \n \n \n \n \n
- \n \n \n \n 2005 - Jean-Louis Leroy – A Timely Start \n \n \n
- \n \n \n \n NYTProf shows you the number of calls and the time \n \n inclusive time – includes the time executing the actual sub \n exclusive time – only the time executing the statement \n \n \n
- \n \n \n \n \n \n \n \n \n OOP \n \n \n Good for code maintainability \n \n \n Its actually killing performance \n \n \n \n \n Functional \n \n \n Better for performance if not overused \n \n \n Easily lures you in performance traps \n \n \n \n \n Better load time may mean \n \n \n worse CPU or Memory usage \n \n \n \n \n \n \n \n \n
- \n \n \n \n Premature optimizations are infecting all of us \n \n Wrongly implemented algorithms or usage of things like for/foreach when you can use while are clear performance hogs. \n \n \n
- \n \n \n \n \n
- \n \n \n \n \n