Re: time after time

"Ger Hobbelt" <[email protected]>
Newsgroups gmane.mail.spam.crm114
Message-ID <[email protected]>
FYI: this was run on a 3.2GHz AMD64 SuSe 10.2 64-bit platform; plenty
of RAM (4GB) and unloaded with other tasks besides the tests
themselves.


On Fri, Jun 6, 2008 at 9:35 AM, Ger Hobbelt <[email protected]> wrote:
> On Fri, Jun 6, 2008 at 2:22 AM, Eric S. Johansson <[email protected]> wrote:
>>     11591   14.870    0.001   14.870    0.001 :0(fork)
>
> To verify this, I created two very basic CRM114 test scripts - so what
[...]
> #    15:    67.522550     1.068977    68.591527     10000    0.006859
> syscall /:*:crm_exe: '-{ window; }'/



For a VERY basic mailreaver.crm invoking syscall the syscall becomes
more than twice as slow (see also exectimingtest2 in attachment in
previous email):

#    18:   155.994599     0.165432   156.160031     10000    0.015616
syscall /:*:crm_exe: mailreaver.crm -- --help/

(Note: vanilla mailreaver.crm does not support '--help'; this is a
feature in the GerH mailreaver which is used here to test the ABSOLUTE
MINIMUM RATING for mailreaver: '--help' loads the script itself, then
prints a bit of output to stdout and exits. No mail is processed, no
CSS files are read or written: no classify or learn is executed here.)

When you fork a CRM114 instance with a mailreaver script which
actually _does_ something useful, you are guaranteed to experience
worse times than this.


What does all this mean?

It means Eric's numbers, listing a fork() cost of >14 seconds for
11591 forks, each instance running crm114, make sense - though they
looked 'impossible' to me at first.



What is lacking?

My CRM114 test scripts do NOT include classify and/or learn
operations. Those should be added (resulting in test script #3 maybe?)
to compare the classify and learn costs with the syscall/fork
overhead.

Nevertheless, I think I can safely say syscall() is a major time hog
when compared to other common CRM114 script expressions, such as
'eval' (which one would expect to consume some power too as it
interprets and evaluates the complete // expression at run-time.


How to speed it up?

Given the minimum rating of 6.8 msecs per forked CRM114 instance on an
unloaded 3+ GHz AMD64 system, there's a lower bound to what one can do
without going the distance by removing the fork. This simple sentence
is feasible only when crm114 comes in a thread-safe library form too -
or as a daemon. Both of which are nontrivial exercises.

The significant speed decrease when loading and running only a few
lines of a large script though, may be a hint that there can be
something gained in the script compiler / executor.
This requires further investigation.


-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.