[cgiapp] size of scripts and dependencies

[P Kishor]

On Sat, Sep 19, 2009 at 9:15 AM, Rhesa Rozendaal <perl at rhesa.com> wrote:
> Richard Jones wrote:
>>
>> Ron Savage wrote:
>>>
>>> Hi Richard
>>>
>>> On Sat, 2009-09-19 at 10:49 +0100, Richard Jones wrote:
>>>>
>>>> Ron Savage wrote:
>>>
>>> [snip]
>>>>
>>>> Hi Ron, hey that's nice - I just used it to profile my current app. I
>>>> modified it slightly to make it a bit less painful on the eyes (though I
>>>
>>> You can't be serious. My code may not be perfect, but it's clear what
>>> it's doing...
>>
>> Yep, though I didn't claim mine was either (just personal preferences at
>> work here, and the temptation to hack to see what can be done), and the use
>> of IO::All in place of manual file handling.
>>
>> And this also works for me:
>>
>> $lines += grep { s/^\s+|\s+$//; $_ !~ /^[{}]?$|^#/; }
>> io($_)->chomp->slurp;
>>
>> though it's still horribly noisy in the grep block (can that be
>> improved?), and doesn't exempt content between =begin & =cut blocks.
>
>
> An approach using PPI would produce more useful results. See
> http://search.cpan.org/perldoc?countperl for example.
>
> Here's the output for CGI/Application.pm:
>
>
> $ countperl /opt/perl/lib/site_perl/5.10.0/CGI/Application.pm
>
> Perl files found:                1
>
> Counts
> ------
> total code lines:        482
> lines of non-sub code:   14
> packages found:          1
> subs/methods:            34
>
> Subroutine/Method Size
> ----------------------
> min:                  1 lines
> max:                  39 lines
> mean:                 13.76 lines
> std. deviation:       9.97
> median:               12.00
>
> McCabe Complexity
> -----------------
> Code not in any subroutine::
> min:                  1
> max                   1
> mean:                 1.00
> std. deviation:       0.00
> median:               1.00
>
> Subroutines/Methods:
> min:                  1
> max:                  16
> mean:                 4.53
> std. deviation:       4.20
> median:               3.50
>
> [Tab-delimited list of subroutines omitted]
>
> As you can see, CGI::Application is in good shape with only 482 lines of
> actual code, 34 subs or methods, and a good size and complexity per method.
>

yes, but... I do realize that the perl interpreter likely tosses the
comments before compiling the code, but isn't there a penalty in
opening a large file, even if most of it is comments? A thousand line
file with 999 lines of comments and one line of code will still need
to be parsed, and it wouldn't matter where in the file the code is,
beginning or end. Perl will have to go through the entire file to
determine what is what.

Now, of course, with 999 lines it probably makes a difference of a few
milliseconds, or not even that, but with 40,000 lines it might be a
different story. Now, keep in mind, it does seem that CGI::App and its
various parts are a lot less than competing frameworks, but 40K lines
scattered over 40-50 odd files means that all those 40-50 files have
to be opened up on every single hit, parsed, and compiled. A few extra
milliseconds here and there would add up over many concurrent hits. Of
course, that is a perfect condition when it makes sense to introduce a
persistent environment such as FastCGI or mod_perl, but they have
other complexities in installation and implementation.

Actually, truth be told, I really don't even have much against the
number of lines. It is in the partially perceived and partially real
difficulty in installing a multitude of interdependent modules just to
get what seems like a simple thing but in reality is quite a
complicated thing... a "simple" db driven website. I use
HTML::Template, so I don't even use CGI::Simple (let alone CGI) for
anything other than $foo = $cgi->param('foo') kind of stuff.

Any move toward making a one click, transparent installation that
brings together templating, db (sqlite, most obviously) and a
persistent environment and a simple but robust web server would likely
gather a lot of brainshare, much like Ruby on Rails has. A
transportable installation would also make it possible for us to make
applications that can simply be copied to a new computer and run.




> rhesa
>






-- 
Puneet Kishor http://www.punkish.org
Carbon Model http://carbonmodel.org
Charter Member, Open Source Geospatial Foundation http://www.osgeo.org
Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor
Nelson Institute, UW-Madison http://www.nelson.wisc.edu
-----------------------------------------------------------------------
Assertions are politics; backing up assertions with evidence is science
=======================================================================
Sent from Madison, WI, United States