| japhb | I remembered that MUGS-UI-CLI doesn't flush the import buffer when it starts up, so you can get real timing for the "adventure startup benchmark" with: | 00:38 | |
| time (echo quit | mugs-cli adventure) | |||
| real0m1.765s | |||
| user0m1.586s | |||
| sys0m0.280s | |||
| Looks like a bit under 1.8s. I forgot to account for my slow-ass keyboard when considering the ^C delay. (For ergonomics, it's fantastic. For input latency, not so much ...) | 00:53 | ||
| greenfork | real0m4.161s | 07:20 | |
| user0m4.867s | |||
| sys0m0.598s | |||
| This is for me with time (echo quit | mugs-cli adventure) | 07:21 | ||
| I will then ask someone who understands --profile, maybe I will be able to debug that. I thought about inter-thread communication too as a source | 07:22 | ||
| By the way, when I run mugs-cli without specifying a server, the server is run in a thread or in a process? | |||
| I assume that UI+Client are run together? Or it is also no the case | 07:23 | ||
| And thanks on the primer for the private variables, I have a much better understanding of them now, regarding the general philosophy too | 07:24 | ||
| japhb | :+1: | 17:18 | |
| Yeah, UI and Client outbound run together, though Client *inbound* (just like Server inbound) runs in its own listener thread. | 17:19 | ||
| When you run mugs-cli and it spawns its own server, it does so using a separate thread and avoids using TCP/IP (it uses inter-thread communication instead) *but* it still uses the same encoding/decoding for the data packets, to ensure that that doesn't get broken, and to make it easier to analyze performance of that in isolation from the network. | 17:21 | ||
| $ faster 4.161 1.765 | 17:23 | ||
| 57.58% less time | |||
| 2.36 times faster | |||
| Ouch | |||
| That just doesn't seem reasonable to me. | |||
| Makes me wonder if Rakudo Star was compiled with optimizations turned off or for generic (two decade old) CPUs or something | 17:25 | ||
| greenfork | I will soon try out the newer version, will see if this is connected to the Star distribution | 17:26 | |
| japhb | Sounds good, thank you! | 17:27 | |
| greenfork | One more about MUGS: when there's some error in my server code for a new game, and I run it with mugs-cli <my-game-name>, I get an error like this | ||
| Died with the exception: Request invalid: Game type 'rrp' is unknown | |||
| And several stack traces pointing to MUGS::App::LocalUI | 17:28 | ||
| Can I improve error reporting somehow? This one happened because I referenced a variable that was not defined in my server code | |||
| japhb | Oh, syntax errors in the game code? That may be causing a failure to load the plugin. | ||
| I'm using a plugin-loader module as a dependency. I'll have to take a look at what can be done about the failure mode there. | 17:29 | ||
| But for myself, I usually have a t/00-use.rakutest that consists of just use'ing all the modules in my distro in dependency order, and I run that test *often*, with verbose test output. It's a canary for "oops, you broke one of the modules not actually involved in startup". | 17:30 | ||
| greenfork | Sounds nice, I will do that too | 17:31 | |
| japhb | If you have an editor that can run tests on file save, that's probably a good thing to hook up to at least the use test. | 17:54 | |
| greenfork | Hmm this is an interesting idea | 18:01 |