The loop was actually a specific # not using $ctime as it would include a 1 sec discrepancy. I just put it there so noone hangs up a slower comp. All the tests were to see if the speed difference with the fish patch on 6.2 vs what we use for 7.17 was in fact all due to fish or due to code execute speeds. If you look at previous posts, it was suggested fish be used as a .mrc script and that native support wasn't needed. It is needed... Glad it's on the todo lists. No I don't want a new thread on multi-core. I was just curious if we could control what routines could be sent to specific cores or the thread pool. And as I suspected, not bloody likely.
And as for significance, the user clames under heavy load in an encrypted environment on several servers on several channels, mirc 6.12 (patched) will hang at maximum 5 seconds on a heavy request load (ie many users searching at relatively the same time). He then points out he gets up to a 15 second hang on 7.17 (script with dll's). Most of the work in his script centers around irc text in priv msg and in chans that are using fish encryption.
Maybe we should all enjoy a 15-30ms delay like someone meantioned. After all, 15 chans more than enough for anybody.
I try my best to encourage users to get a shell so they can use the same type of script using perl and sql. But not everyone wants to a pay monthly fee so some prefer the mirc version of my utility. And mostly a lot less complicated to install for novice users who want to use it.
Not only will it make mirc more appealing and convenient to use, it'll make encryption/decryption faster. And by the looks of it I need all the help I can get. What are u going to suggest now? Tell all the users of my script to overclock cpu to keep up?
A simple routine... lol Next time I'll paste 10,000 lines and u can pick which command was a better example for comparison. You keep asking "what tests?" "what tests?". JUST CODE SOMETHING AND RUN IT ON BOTH!!! Are you that lazy???