Jump to content

SetElementData vs TriggerServer/ClientEvent


Recommended Posts

I've got a performance question, let's put the hypotetical case where I want to make players showing bubbles like "writting..." when they're typing in the chat, I don't have any issue making a script like that but my question is about performance, now let's say that to sync this information with other players I use setElementData, then every player in the server "knows" who's writting, but the problem is that everyone his mother knows how CPU intensive SetElementData can be if it's constantly triggering.

In the other hand let's say that to make a more optimized system, I first get in the client side like all the players in a radious of 100 units then make a table with all the players in this radious, send it via TriggerServerEvent, then send back the information to the players in the table using the first optional argument of triggerClientEvent.

 

Which would perform better, and more important how CPU intensive is sending tables via TriggerServerEvent?

Link to comment
  • Moderators

Trigger events will use around 3 t/m 7 times more network(I do not know the exact multiplier) per player incompare to elementdata.

* send tables over without much impact on the network.

* can indeed be send to specific players.

* do also have a latent variant which doesn't block the network.

* require more code to sync.

 

Elementdata

* is a logic method to add properties to an element. (Which has more or less to do with the name of functions)

* always synced with all players

A single * execution of a single connection has relative low impact on the network. Player > server

* each set counts as an update of the server and the other clients. (CPU)

 

Both methods trigger the event system. Just specific trigger events should technically trigger specific clients only.  (specific performance details of the cpu are not known by me)

 

So pick which you think that is right.

 

Thought, I wonder if using the UDP protocol through a browser might be using the lowest amount of data.

 

Edited by IIYAMA
Link to comment
  • Moderators

@Flower ☠ Power

More RAM? I am not sure.

ElementData has as nasty after effect that, the data remains in the memory (even the server) after it has been set. This has to be cleared manually. Stopping a resource doesn't clear it, unless it is applied to a >destroyed< element of that resource.

But it might be true that the triggerEvent uses more RAM while being executed, as it is a more direct method. If you trigger from one side to another side (without latent events), you will notice that it is a high priority network request, while elementData is being send/received after a (few) frame(s). << not sure how elementData is prioritised.

I haven't been in to the development of MTA, so keep in mind that there might be other explanations for these results, as everything that I am saying is based on my own experience.

Edited by IIYAMA
Link to comment
  • 1 month later...
On 09/11/2018 at 00:06, IIYAMA said:

@Flower ☠ Power

More RAM? I am not sure.

ElementData has as nasty after effect that, the data remains in the memory (even the server) after it has been set. This has to be cleared manually. Stopping a resource doesn't clear it, unless it is applied to a >destroyed< element of that resource.

But it might be true that the triggerEvent uses more RAM while being executed, as it is a more direct method. If you trigger from one side to another side (without latent events), you will notice that it is a high priority network request, while elementData is being send/received after a (few) frame(s). << not sure how elementData is prioritised.

I haven't been in to the development of MTA, so keep in mind that there might be other explanations for these results, as everything that I am saying is based on my own experience.

Thanks for the answer and sharing your own experience, I think I might stick to triggerEvent looks like more manual but it seems that it's way cleaner than elementData.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...