Plugins known to cause lag?

So I'm trying to strip down my mod collection, to reduce lag and rubberbanding for my players.

Are there any plugins known for causing alot of lag?

 

I think it would be easier if you show us what plugins you are using

 

Teleport might cause lags , make sure u clear tp saves from data in called m-Teleportation.json i think, but do that only at wipes.

 

The only one that I know that would cause some lag is AutoDoors for Rust | Oxide but only if you have a lot of bases how many I have no idea it would be ok on a low size map with low amount of bases

 

There is as I have tested it and have now removed the plugin and lag has stopped I know its your plugin but if you have a large map with many bases and say 150 players online and doors opening and closing all the time yes it will cause some lag but yes it depends on many things on how bad the lag would be if say you had a good server then it would not be a problem but if you say host with gameservers then it would lag a lot

 

I tested with this plugin installed only lag stopped when it was removed yes lag was not to bad but it was there

 

People seem to think timers are the devil.

 

So say 50+ bases each with say a min of 100 doors would that cause lag for the plugin

 

Timers aren't really any more complicated than telling code to run a specific time (interval) and a specific number of runs. As far as I know, there's no magical reason for timers to cause any extra "lag" more than running the code regularly would.

 

Well will test the plugin more for the next few weeks/months see how it goes

 

For those wondering about performance, you can just check it yourself: Oxide/Timer.cs at 97ef5efb94fa001e08481bcbfba3029051f8f8fe · OxideMod/Oxide · GitHub

It's a pretty simple concept, really. Every frame you check whether your timers should fire. You start checking at the one that fires next, proceed in order and stop checking when you reach the first timer that doesn't need to be checked
Oxide even limits the frequency of that check to 40Hz, so if your server is running at 900 fps, it'll still just check timers 40 times a second.
Timers rarely ever execute in the same frame. This means that oxide only executes a single check for the first timer (and rarely a second one for the second timer) 40 times a second, which is nothing.
What is however expensive is checking whether a timer was destroyed from the outside, which iterates all timers, although arguably not expensive enough to cause significant lag.
All those statements are very branch prediction friendly and lists should be cache friendly enough.

There are some things that can be improved in that timer implementation, but occasionally simplicity trumps performance, and the advantages here are minor.
Possible improvements:

• Use binary search on the fully sorted list, this might reduce overhead for inserting new timers.
• Use an array min-heap instead of a fully sorted list. This might improve performance for both inserting and destroying timers.

Either way, inserting and destroying timers are a damn rare operation compared to checking timers.
[DOUBLEPOST=1460382175][/DOUBLEPOST]I forgot to add something about the timer destroyed flag in my last post.
It's probably also a good idea to add the timer to a "timer destroyed" set when calling stop instead of checking all timers every frame.
This should reduce overhead each frame further, and now that I think about it, this is probably the most expensive operation in most frames.
[DOUBLEPOST=1460382848][/DOUBLEPOST]Sorry for spamming this, but to extend on my statement that it shouldn't be expensive enough to cause significant lag:
The worst case when looking up the destroyed flag would be two cache misses, one for accessing the i-th element in "timers", which might be allocated on the heap, and one for accessing the timer flag, which might be allocated on the heap as well.
On average a cache miss takes 120ns. For 1000 timers that's 240μs compared to the 4ms a frame takes at the usual 250fps. Adding this to the frame time you get to 4.24ms, which is still 235fps, a mere 15fps overhead at 1000 timers running at once, assuming that oxide runs this every frame, when in reality it limits this process to 40Hz.
So while it does introduce a slowdown, it's not a significant amount of lag (not to the degree that it's noticable) and I highly doubt that people will ever have 1000 open doors at once, even on a 100 people server.

 

Door share does cause bucket loads of Lag.
Door Share for Rust | Oxide

It's one of the worst offenders, any time anyone places or uses a door it can cause an up to 3.7second delay in code.

Example:
(18:51:27) | [Oxide] 13:51 [Warning] Calling 'OnItemDeployed' on 'DoorShare v1.1.2' took 2414ms [GARBAGE COLLECT]
(18:51:29) | [Oxide] 13:51 [Warning] Calling 'OnItemDeployed' on 'DoorShare v1.1.2' took 1222ms
(18:51:30) | [Oxide] 13:51 [Warning] Calling 'CanUseDoor' on 'DoorShare v1.1.2' took average 3776ms

Since removing it lag has dropped tonnes.

It would be epic to see some form of command in Oxide to display memory usage by all plugins and potentially CPU time if relevant.

 

If you are getting a lot of warnings like that it means your server is not fast/powerful enough to handle the players or running the server