The example is Protocols.HTTP, which is almost twice as slow. But
maybe it loads Calendar internally?
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
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.
Mabye it should cache the timezones in a decode_value data file?
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.
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().
That parsing shouldn't take that long. Something is strange. Is sscanf
extra slow on ARM?
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.
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.
0.18 seconds to load the perl modules - the pi is 50 times slower.
Actually closer to 100x, if you are looking at raw CPU performance.
However, memory speed is probably somewhat important as well, it is
only about 10x slower there.
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.)
I'd rather suspect AC_PROG_CXX, which was added in this commit:
commit bf4cdfefc4574f2bc59463022578d758bbd29e11
Author: Henrik Grubbström (Grubba) gru...@grubba.org
Date: Mon Feb 14 13:42:35 2011 +0100
Improved support for modules needing C++ compilers.
12 matches
Mail list logo