Frederic -
Thanks for your work on profiling the code. I haven't tried it myself,
but I've heard great things about the NY Times Profiler.
http://open.blogs.nytimes.com/2008/03/05/the-new-york-times-perl-profiler/
http://search.cpan.org/dist/Devel-NYTProf/
thought it might be a useful tool if
>> Yes, but context objects will be created 23 times, one per module using
>> C4::Context. I just send a patch which uses class variable for default
>> context.
> Good eye, Frédéric.
A tribute must be paid to MJ Ray who expressed his astonishment about
C4::Context::read_config_file being called
On Wed, Jul 2, 2008 at 2:31 AM, Frederic Demians <[EMAIL PROTECTED]> wrote:
> Yes, but context objects will be created 23 times, one per module using
> C4::Context. I just send a patch which uses class variable for default
> context.
Good eye, Frédéric.
Thanks!
-Andy
_
>> Why isn't it as simple as caching the result, as in
>
> I think it probably really is that simple, at least for now - could
> you test your approach and submit?
Yes, but context objects will be created 23 times, one per module using
C4::Context. I just send a patch which uses class variable f
Hi
2008/7/1 Galen Charlton <[EMAIL PROTECTED]>:
> Hi,
>
> > I think so. I don't recall setting up XSLT explicitly, but I've
> > certainly had errors about invalid marcxml spat at me.
>
> Right; because all MARC records are processed through MARC::File::XML
> at various points, there will be XML p
Hi,
On Tue, Jul 1, 2008 at 9:06 AM, MJ Ray <[EMAIL PROTECTED]> wrote:
> Frederic Demians <[EMAIL PROTECTED]> wrote:
>> So reading config file may be not so slow but it is called 23 times! If
>> you add a warning in this procedure, you see it is called from those
>> modules: [...]
>
> Why isn't it
Frederic Demians <[EMAIL PROTECTED]> wrote:
> So reading config file may be not so slow but it is called 23 times! If
> you add a warning in this procedure, you see it is called from those
> modules: [...]
Why isn't it as simple as caching the result, as in
diff --git a/C4/Context.pm b/C4/Conte
> These %s add up to considerably more than 100% don't they? What does
> that mean?
This is a dprofpp -I result. It means that it displays subroutine times
inclusive of child subroutine times. I suppose for example that
C4::Context::new call C4::Context::read_config_file that call
XML::Simple:
Frederic Demians <[EMAIL PROTECTED]> wrote:
> Profiling an OPAC search with dprofpp -I gives this result:
>
> Total Elapsed Time = 4.046462 Seconds
> User+System Time = 3.676462 Seconds
> Inclusive Times
> %Time ExclSec CumulS #Calls sec/call Csec/c Name
> 38.6 0.008 1.420 1 0.0081 1.
On Tue, Jul 01, 2008 at 09:51:56AM +0200, Paul POULAIN wrote:
> Wojciech Zatorski a écrit :
> > btw: using Koha without mod_perl is bg efficiency mistake.. ;)
>
> does it mean you use Koha 3.0 with mod_perl currently ? and you don't
> have any problem with it ? That would be good to know...
>
Profiling an OPAC search with dprofpp -I gives this result:
Total Elapsed Time = 4.046462 Seconds
User+System Time = 3.676462 Seconds
Inclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
38.6 0.008 1.420 1 0.0081 1.4195 C4::Search::searchResults
35.6 0.030 1.310
Hello Paul,
Tuesday, July 1, 2008, 9:51:56 AM, you wrote:
PP> does it mean you use Koha 3.0 with mod_perl currently ? and you don't
PP> have any problem with it ? That would be good to know...
nop.. i still using Koha 2.2.x with PerlResponseHandler
ModPerl::RegistryPrefork,
version 3.0 is still
Wojciech Zatorski a écrit :
> Witaj Chris,
>
> W Twoim liście datowanym 30 czerwca 2008 (21:03:31) można przeczytać:
>> Or indeed both memcached and mod_perl :)
> btw: using Koha without mod_perl is bg efficiency mistake.. ;)
does it mean you use Koha 3.0 with mod_perl currently ? and you don
Witaj Chris,
W Twoim liście datowanym 30 czerwca 2008 (21:03:31) można przeczytać:
> Or indeed both memcached and mod_perl :)
btw: using Koha without mod_perl is bg efficiency mistake.. ;)
bye
--
The Main Library of Szczecin University.
Computerization Department.
http://bg.univ.szczecin
>
>
> Correct me if I'm wrong but I fear that a huge amount of time is burnt
> just reading Koha XML config file (do you see anything else?) Koha
> config file being an XML file is a good thing. It's not even a problem
> if reading XML file in Perl is slow (could be for MARC records). But
> this fi
> (continuing investigations)
> I tried to investigate -d:DProf, but could not run a search with DProf.
opac-main.pl page profiling with Dprof give this result:
Total Elapsed Time = 1.573963 Seconds
User+System Time = 1.503963 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c
(continuing investigations)
I tried to investigate -d:DProf, but could not run a search with DProf.
I modified the 1st line of opac-search.pl, to have #!/usr/bin/perl
-d:DProf, but get the following error :
> [Mon Jun 30 16:33:19 2008] [error] [client 127.0.0.1] Can't call
> method "config" o
Witaj Wojciech,
> GPRS connection:
> Opera Mini (JAVA) - ~5s
> Opera Mobile 9.5 - ~10s
not GPRS but EDGE connection...sorry..
bye
--
The Main Library of Szczecin University.
Computerization Department.
http://bg.univ.szczecin.pl
___
Koha-devel maili
Hello MJ,
Friday, June 27, 2008, 7:36:15 PM, you wrote:
MR> Frederic Demians <[EMAIL PROTECTED]> wrote:
>> > - opac-results = 16kB (3 results in my tests). OK, not too much
>> > - css = opac.css is 28kB, others (ui.css & print.css) are 2.xkB. Could
>> > opac.css be "smallified" ?
>> > - js = 300K
> No, the difference between 16Kb and 100Kb is not peanuts. 16Kb will
> display on nearly all mobile phones. 100Kb will not.
You're shifting to another subject. Improving Koha usability with mobile
devices is interesting by itself but is not the question. Paul question
is about relation betwee
Frederic Demians <[EMAIL PROTECTED]> wrote:
> > - opac-results = 16kB (3 results in my tests). OK, not too much
> > - css = opac.css is 28kB, others (ui.css & print.css) are 2.xkB. Could
> > opac.css be "smallified" ?
> > - js = 300KB !!! with utilities.js being 100KB !!! that's huge !!!
>
> Thank
Hello Frederic,
Friday, June 27, 2008, 6:03:39 PM, you wrote:
>> - opac-results = 16kB (3 results in my tests). OK, not too much
>> - css = opac.css is 28kB, others (ui.css & print.css) are 2.xkB. Could
>> opac.css be "smallified" ?
>> - js = 300KB !!! with utilities.js being 100KB !!! that's hu
> - opac-results = 16kB (3 results in my tests). OK, not too much
> - css = opac.css is 28kB, others (ui.css & print.css) are 2.xkB. Could
> opac.css be "smallified" ?
> - js = 300KB !!! with utilities.js being 100KB !!! that's huge !!!
Thank you for raising this question. JavaScript and CSS is c
Hello,
I just did some tests on opac (a simple search), and save the
html/css/js/...
Here is my analysis :
- opac-results = 16kB (3 results in my tests). OK, not too much
- css = opac.css is 28kB, others (ui.css & print.css) are 2.xkB. Could
opac.css be "smallified" ?
- js = 300KB !!! with uti
24 matches
Mail list logo
