I noticed Pike takes a very long time starting on the Pi.
It seems to have to do with module loading:
pi@raspberrypi:~$ time pike -e 'write("test\n");' test
real 0m2.774s user 0m1.450s sys 0m0.050s
2.7s is slow, but not devastating.
pi@raspberrypi:~$ time pike -e 'import Protocols.HTTP; write("test\n");' /usr/local/pike/8.0.10/lib/modules/SSL.pmod/Connection.pike.o:-: Warning: Decode failed: Decode error: Got unfinished program <116> after decode: program(/usr/local/pike/8.0.10/lib/modules/SSL.pmod/Session.pike) test
real 0m24.972s user 0m12.760s sys 0m0.270s
25s is a bit tardy. The error message might be a clue?
Loading Calendar takes 14 seconds.
This is repeat performance, so it's probably not a slow disk (SDCard). Anything I can do to make this more tolerable/debug the problem?
The Calendar module is, as you know, exceptionally slow. Do you get similar problems with other modules?
The example is Protocols.HTTP, which is almost twice as slow. But maybe it loads Calendar internally?
Protocols.HTTP uses the calendar module to decode http dates.
If everyone in the http land just used the GMT timezone as specified this would not really be needed, and perhaps now it would be safe to switch to System.TM or just mktime().
Or Calendar.ISO_UTC, which doesn't load timezones. Or at least that's what it was made for... It seems pretty exactly the same level of slow now.
It's also used in the _sprintf method for cookies, but that doesn't seem that important...
Pike 8.0 is a lot slower than 7.8 when it comes to loading Protocols.HTTP (Mirar's test case).
The difference doesn't seem to be in Protocols.HTTP itself, but rather that Standards.ASN1.Types depends on the Calendar module since 8.0 (and ASN1 is a dependency of SSL, which in turn is a dependency of Protocols.HTTP.Query.)
On my slow arm (about 50% the speed of a pi) it takes about a minute to load the calendar module. Almost all that time is parsing timezones.
So, limiting the size of the timezone file for slow devices would help.
This is somewhat surprising, becase I can not remember it taking minutes to load the calendar module on a 110Mhz SPARC. And those are slower, albeit not that much, than my slow arm.
I have tried that, and it is somewhat hard because they are compiled to objects in several mappines/lists. Adding _encode and _decode and then using encode/decode value does not really make things all that much faster.
I think that if it had been a problem on the old computers - which shouldn't be that much faster than a pi - I would have picked another solution for the timezones. I really wonder what's going on.
Perl and python aren't very fast either, it seems.
Perl takes 10 seconds to execute sendxmpp. 1 second of that is protocol negotiation. On the PC that operation takes 1.18 seconds, so 0.18 seconds to load the perl modules - the pi is 50 times slower.
I can't spot where the delay is in Calendar, can you give a pointer?
For me there's a delay between loading Calendar and Timezone.Parse_all_rules of 10 seconds, and then the parsing takes "just" one second. (Which is still slow. But anyway.)
That parsing shouldn't take that long. Something is strange. Is sscanf extra slow on ARM?
Since we are so fond of precompiling modules, can't we also precompile the timezones?
pike-devel@lists.lysator.liu.se
-
Marcus Agehall (nu med K-m�rkt fastighet och ny elcentral) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Karlgren (arga kodarn) ＠ Pike (-) developers forum
-
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Mirar ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum