Lag on ListenerOnJoinEvent

[AllyncID]

How to fix this issue?

[sekwah41]

Ive seen gateway join event lag but never specifically this one. Typically, this shouldn't be that inefficient. What fork of Spigot are you using?

[AllyncID]

UniverseSpigot

[sekwah41]

What version of mc are you using, also would you mind testing a different performance fork to see if this is consistent? I've never heard of UniverseSpigot.

The issue here is most of the wait time seems to be from async task handlers so I don't believe the lag is from my plugin rather than deceptively may be looking like its coming from my plugin due to the async wait times.

Though I haven't tried to debug timings in a while and may be wrong.

Nothing in the code surrounding those checks should be inefficient to my knowledge and it should only be doing a single check for the block type. I suspect this may be something wed want feedback from the maintainers of UniverseSpigot.

[sekwah41]

Advanced-Portals/src/main/java/com/sekwah/advancedportals/bukkit/listeners/Listeners.java

Lines 95 to 118 in 6a228d8

	public void onJoinEvent(PlayerJoinEvent event) {
	Player player = event.getPlayer();
	if(player.hasMetadata(HAS_WARPED)) player.removeMetadata(HAS_WARPED, plugin);
	Portal.joinCooldown.put(player.getName(), System.currentTimeMillis());
	Location loc = player.getLocation();
	Location eyeLoc = player.getEyeLocation();
	UUID uuid = player.getUniqueId();
	for (AdvancedPortal portal : Portal.portals) {
	if (!portal.inPortal.contains(uuid)
	&& (Portal.locationInPortalTrigger(portal, loc) || Portal.locationInPortalTrigger(portal, eyeLoc))) {
	portal.inPortal.add(uuid);
	}
	}
	Map<String, String> playerMap = plugin.getPlayerDestiMap();
	if (playerMap.containsKey(uuid.toString())) {
	Destination.warp(player, playerMap.get(uuid.toString()), false, true);
	playerMap.remove(uuid.toString());
	}
	}

Here is the code in question.

Actually, how many portals do you have? I may be best to make the loop more efficient by checking the material only once. Though unless you have a lot of portals it doesn't explain a noticeable lag spike, or are you just trying to look for any performance improvements?

[sekwah41]

Advanced-Portals-1.0.0.jar.zip

Please give this a test; if it's still having the same performance issue, then you will need to talk to UniverseSpigot. This check shouldn't be that inefficient anyway, even if it's repeated like 30 times or so.

[AllyncID]

Okkk... thank you sir, lemme try

[sekwah41]

Sorry the responses were a bit spammy, you caught me in a heavy dev mood with all my code editors open xD and I couldn't not experiment a little 😆

[sekwah41]

Any news on this?

[AllyncID]

same

[AllyncID]

https://spark.lucko.me/T203W843EJ

[sekwah41]

I'll try to take a look at the timings tonight though i don't think I'll have time to make any changes.

Could you try another fork to see if your setup has the same issue on things like paper?

I'm curious about what UniverseSpigot has to say about these logs as most of the % seems to be in the mc code on asynchronous waiting at a glance.

[sekwah41]

Actually I can't seem to find much info about universe spigot at all online. Could you link me to their website or something?

[AllyncID]

https://discord.gg/5c2mKKTG they're only on discord

[sekwah41]

Closing this issue as the timings are entirely pointing towards the concurrency code, causing this latency issue.

Tbh given the fact that the tps isn't having an issue at all its likely a false positive where its freezing using the concurrency locks so the function itself may be taking a while, but its allowing other parts of the tick to process.

Seeing as the entirety of the waiting time is attributed to Unsafe.park, this is why I believe it's a false positive.

The other evidence that this is pointing towards a false positive is the fact that Advanced Portals shows to be taking about 40-50% of the tick however the average MSPT is actually lower than the previous ticks in the logs you sent me.

If you are able to show this issue happening on another fork like Paper or Pufferfish I will look into it more though there is too much evidence pointing towards a false positive.

[sekwah41]

I would suggest opening a ticket and getting them to weigh in. Though unless there is a clear issue I can fix with my code this will be either a false positive. Or an issue on their end.

[MachineBreaker]

UniverseSpigot developer here, this is not caused by us and this can happen on every fork including Paper, this happens because the chunk was unloaded at that time so getting the block type caused it to be loaded synchronously

[sekwah41]

@MachineBreaker thanks for the info :D so yea I assume it’s a false positive due to it freezing for a chunk load. Which seeing as the player is joining will likely have to be done for that chunk anyway.

Though if it causes a noticeable increase I guess I could look into hooking into other events for when the chunk is finally loaded.

Feel free to correct me if I'm wrong but it seems like a non issue for both my plugin and any forks of paper atm.

[MachineBreaker]

@MachineBreaker thanks for the info :D so yea I assume it’s a false positive due to it freezing for a chunk load. Which seeing as the player is joining will likely have to be done for that chunk anyway.

Though if it causes a noticeable increase I guess I could look into hooking into other events for when the chunk is finally loaded.

Feel free to correct me if I'm wrong but it seems like a non issue for both my plugin and any forks of paper atm.

You can probably try delaying your checks for like 1 tick to potentially allow the server load the nearby chunks? Unsure if that could work

[sekwah41]

Actually, I am going to re-open this as it would be good to avoid the server loading the chunks synchronously. I believe they are loaded async but this call at least forces it to load before it can advance. This would be a larger issue on some servers if loaded from a slower hard drive.