heavy builtin usage question

[Nathan Smith]

Hi there,'So this problem has been bugging me for a while, and I finally decided to ask the general community in hopes of getting a definitive answer:

Builtins block the server, right?

So for example, if I had a builtin called, I don't know, block, and passed it block(60), it would stop everything, commands, tasks, everything on the server, for 60 seconds.

So based on that, why do we have builtins? I mean somethings are obvious. file i/o, for example, is useful, but surely, an over usage of builtins would cause the server to stutter and eventually just give up the ghost.

In my below examples, I used ISA, because I've been speaking about it a lot recently.

In the standard lambda  core, $ou:isa has a call to $cu:sin, which can lag the server if it is run multiple times on several hundred objects, $cu:sin likes to lag, don't know why it just does.

So, the next obvious step is to instead send $ou:isa straight through, after error checking, to the builtin isa, right?

But surely, isa is a blocking function, and therefore, every time isa is called, the server haults for 0.000000 what ever seconds. Lets say for arguments sake, 0.001 seconds.

So, if isa is called 1000 times, the server locks for a seconds. Surely programmers want to avoid that completely@
?

Iight be wrong, so please correct me if I am.

Thanks for clarifying this weird thought train.

Nathan

[Tristan Bussiere]

1. $cu:sin does not 'like to lag the server'. Poorly written or
optimized verbs can lag the server, and these usually go hand-in-hand
with $cu:sin as they'll be persistently calling it to continue
execution.
2. Builtins are many times faster than MOOcode since they run
natively. Builtins have access to C libraries that you cannot access
with MOOcode. I can't even follow your isa example; I just ran isa on
a MOO with 380,000 objects and it took 1.5 seconds to completely
iterate through the entire list. Obviously, this is dependent on your
server's CPU, but running isa many times does not create perceptible
lag on any modern system unless you run it hundreds of thousands of
times in one single go. Even then, if you are constantly running isa
on thousands of objects
in a loop, you should probably look into caching.
3. Over usage of builtins does not cause stuttering or 'giving up the
ghost'. Without builtins, your database wouldn't have any way of
properly operating. Player:tell, for example, is just a wrapper around
the notify() builtin. This gets called every second of every day on
popular MOOs, often being called dozens of times per second.

Rather than immediately blaming isa or $cu:sin for lagging, I advise
you post us examples of code that lags. Profile some more.

> --
> You received this message because you are subscribed to the Google Groups
> "MOO Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to MOO-talk+u...@googlegroups.com.
> To post to this group, send email to MOO-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/MOO-talk.
> For more options, visit https://groups.google.com/d/optout.
>

[Littlefield, Tyler]

Comments inline:

On 3/1/2019 8:41 PM, Nathan Smith wrote:

Hi there,'So this problem has been bugging me for a while, and I finally decided to ask the general community in hopes of getting a definitive answer:

Builtins block the server, right?

Yes.

So for example, if I had a builtin called, I don't know, block, and passed it block(60), it would stop everything, commands, tasks, everything on the server, for 60 seconds.

Sure, if you had it just wait for 60 seconds. It could also be suspend(60) in which case it suspends the task and doesn't block the server.

So based on that, why do we have builtins? I mean somethings are obvious. file i/o, for example, is useful, but surely, an over usage of builtins would cause the server to stutter and eventually just give up the ghost.

Builtins can be much much faster than MOO code, even on very large chunks of data. It doesn't block the server so hard that it studders, and I'm still of the oppinion that you're looking in all the wrong places to diagnose your lag. MOO code can call sin if needed on large amounts of data, but I prefer to let builtins deal with larger chunks of data until I know that there is indeed a performance problem there. Pointing your finger and assuming it's builtins or ISA or any of the others you've tried to figure out so far is only premature optimization without proper evidence to back that up.

In my below examples, I used ISA, because I've been speaking about it a lot recently.

In the standard lambda  core, $ou:isa has a call to $cu:sin, which can lag the server if it is run multiple times on several hundred objects, $cu:sin likes to lag, don't know why it just does.

Have you not read the code for $cu:sin? Does it not tell you what it's doing? There's also a difference in suspending when your ticks are low and lagging).

So, the next obvious step is to instead send $ou:isa straight through, after error checking, to the builtin isa, right?

That's what most of us do, yes.

But surely, isa is a blocking function, and therefore, every time isa is called, the server haults for 0.000000 what ever seconds. Lets say for arguments sake, 0.001 seconds.

Probably less than that, it would be very easy to write timing code to find out for sure. That said, users aren't going to notice a quick 0.001 second pause.

So, if isa is called 1000 times, the server locks for a seconds. Surely programmers want to avoid that completely@
?

It would be called 1000 times through the duration of a task, and the server could slice that task up and do other things. I'm not saying that builtins are the solution always, but they're not going to just bring your server to it's knees by calling ISA.

Iight be wrong, so please correct me if I am.

Thanks for clarifying this weird thought train.

Nathan

--

You received this message because you are subscribed to the Google Groups "MOO Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+u...@googlegroups.com.
To post to this group, send email to MOO-...@googlegroups.com.
Visit this group at https://groups.google.com/group/MOO-talk.
For more options, visit https://groups.google.com/d/optout.

--

Take Care,
Tyler Littlefield Tyler Littlefield Consulting: website development and business solutions. My personal site My Linkedin @Sorressean on Twitter

[Michael Munson]

If you think a particular built-in is lagging your server (it probably isn't) the solution is to use the $server_options.protect_<builtin> switch and then create a MOO verb that implements whatever the built-in does. For example, if you have a isa() built-in, you could make a #0:bf_isa verb that is called instead of the isa() that just does it the way $object_utils does it. Then compare your server with the built-in running and with the MOO code implementation running.

Michael

[Littlefield, Tyler]

Alternatively, use bf_* to profile isa to make sure it's not taking as long as you think.

[Nathan Smith]

hi everyone,

After the point was made that notify is indeed a builtin, I literally hit myself over the head.

I reenabled the bbuiltin isa for stunt... and hit huge problems, and so disabled it, temporarily.

Is there something with the isa? I don't mean lag, I mean two server crashes in a day.

I'm going to do a valgrind on it to find out the actual code rror, but... wondered if this was common.

Thanks