The TinTin++ message board

[Amity88]

I'm new to this forums but I've been using Tintin since a couple of years, needless to say, I love it! The scripting is straightforward and it runs on all sorta systems. Recently, I've been playing with Mushclient and came across a benchmark they did http://www.gammon.com.au/mushclient/benchmarks_old.htm and another one at zMud https://www.zuggsoft.com/zmud/bench.htm.

I don't see Tintin in either of those lists and I was considering doing a benchmark myself. However, before I do that, I thought I'll ask you guys about its relevance considering how fast modern hardware is. I find it odd that a pure terminal client like telnet would be rated so low in their benchmark. So, any thoughts?

[Scandum]

Those benchmarks are kind of silly.

It measures how fast terminal emulation is, but that's just a small aspect of overall client speed.

They benchmark the processing speed of 4300 lines on old machines while the average mud sends between 1 and 20 lines per second. If a client is slow the terminal speed has little to do with it.

I've heard many people state that tintin++ is faster than both mushclient and zmud.

Being faster than zmud makes sense because Zmud has a lot of bloat. This is understandable as it's harder to say no to paying customers requesting features less than 1% of the users actually use.

Mushclient uses Lua while tintin uses a lot of hardcoded core routines. So that likely explains performance differences in that regard.

[PowerGod]

Maybe should be better to try them with a server in the same PC or in a very little LAN... just to be almost sure that the response time is always the same...

Also comparing the file access/reading/writing speed can be interesting, anyway the precision should be very high with modern hardware.

Unluckily doesn't exist an ACID test like the one for the Browsers...but one can made a little script for every client trying to include the most common instructions, recording the execution time for every step...

The explanation why Telnet was so slow is in this sentence

[Amity88]

@Scandum,
Thanks for clearing things up, the one mud I play has these events where text would scroll like crazy, I think maybe 200-700 lines a second. During that, I notice that the scrolling isn't entirely smooth but comes in quickish chunks. That and the effects of having many many triggers is the reason why I was curious of the speed.

Oh, also, I tried running lua in another session like how you had shown at the website to see if I can play around with it. I would capture the mud text using an RECIEVED LINE event and pass it to lua for some text manipulation. It did slow down the scrolling speed.

I looked into the source code to figure out ways to optimize my tintin scripts and I have a bunch of questions for you, if you're free some time.

@Powergod
Yes, I plan on running a mud server on a VM on the same PC so that network lag wouldn't influence the measurements.

I'm not so sure about the file access speed measurement, I feel that has more to do with the OS than the client itself. I think the OS buffers the data before flushing to disk and we're gonna be reading/writing just a few Kb's at the most

[PowerGod]

I'm interested in file reading/writing speed because I use them a lot, even as a database (without index!!), and I've seen visible different speeds from one client to another many years ago (all on the same PC and OS)

Maybe some of them were using different libraries...

As far as I know TinTin++ is the only one that can use directly OS functions for this purpose.

[Scandum]

#script is blocking, where as #run is not. So if you need to do something very taxing it's an option to use #run.

Still have to look into improving communication between sessions.

I'm sure there are some bottlenecks in tintin, I try to avoid writing slow code but it's not always my main priority.

[Amity88]

@PowerGod,
Oh, I hadn't thought of that. I only do file I/O for logs and when loading scripts/map files. Now I'm curious as to why the other clients had slower file processing. Maybe the data structures they use are unnecessarily complex and bloated, or maybe they have a lot of processing steps after file read? I'm only speculating.

@Scandum,
I used the #RUN command like you had mentioned in this link. Then I passed back the entire mud output to it using an #EVENT {RECIEVED OUTPUT} {#lua script_func %0} but the scrolling slowed down slightly after that.

As for the questions, my goal is to write scripts in a way that I can use the faster commands in the tintin script while avoiding the things that cause a slowdown.

1) Does the #REGEXP {} {{expn}} {} command directly invoke the pcre library? I've heard that perl regex is pretty fast, so does that mean that using a REGEXP match on mud output to call an alias would be faster than a plain old #ACTION?

2) Is it better to use #SEND instead of simply typing out the mud command within an alias or trigger? I'm wondering about this cause with the #SEND, wouldn't the extra text-input-parse step be eliminated?

3) How exactly does the packet-patch and color-patch settings affect the packets/ mud output? I've noticed some intermittent colour bleeding when a large amount of multicoloured text scrolls past and those two settings seem to help.

4) Is the use of a #FUNCTION command faster than say using an #ALIAS to do the equivalent calculation and asignment?

[Scandum]

1) There's no difference as tintin regular expressions are translated to PCRE equivalents. The execution speeds are identical.

2) #send is slightly faster, especially if you have a lot of aliases.

3) packet patch shouldn't impact the output, color-patch adds color codes and should be slightly slower. color-patch is only needed on a few MUDs, primarily IRE muds.

4) alias should be faster.