SpigotMC / BungeeCord

BungeeCord, the 6th in a generation of server portal suites. Efficiently proxies and maintains connections and transport between multiple Minecraft servers.
https://www.spigotmc.org/go/bungeecord
Other
1.54k stars 1.1k forks source link

[Suggestion] Cloudflare optimized zlib #3125

Closed Janmm14 closed 3 years ago

Janmm14 commented 3 years ago

Cloudflare optimized zlib(https://github.com/cloudflare/zlib) is much faster than upstream. I've been using this branch for years in my other project.

Some other deflate compatible implementations such as libdeflate are also faster than zlib, but the compressor needs to be refactor.

Originally posted by @caoli5288 in https://github.com/SpigotMC/BungeeCord/issues/3114#issuecomment-865216596

caoli5288 commented 3 years ago

I think you should test and benchmark first instead of opening an issue and quote what I said. Right?

My intention is to discuss possible options, not to make a formal proposal, which requires more rigorous test data rather than a conversation.

MrIvanPlays commented 3 years ago

my suggestion to natives is to do what we did to packet initialisation - replace reflections with suppliers. same for channel initialisations - use channel factories rather than initialising channels with reflections. however, most good improvements never come true in bungeecord or in spigot due to people like caoli5288 or md_5. I'm even amazed md_5 accepted the change of replacing packet initialisation from reflection with suppliers!

Janmm14 commented 3 years ago

@MrIvanPlays I don't see reflection in channel initialisation?

caoli5288 commented 3 years ago

my suggestion to natives is to do what we did to packet initialisation - replace reflections with suppliers. same for channel initialisations - use channel factories rather than initialising channels with reflections. however, most good improvements never come true in bungeecord or in spigot due to people like caoli5288 or md_5. I'm even amazed md_5 accepted the change of replacing packet initialisation from reflection with suppliers!

Please reduce your personal attacks. It's meaningless.

caoli5288 commented 3 years ago

Here are some discussions about cloudflare's zlib.

http://www.htslib.org/benchmarks/zlib.html https://github.com/zlib-ng/zlib-ng/discussions/871

MrIvanPlays commented 3 years ago

@MrIvanPlays I don't see reflection in channel initialisation?

https://github.com/SpigotMC/BungeeCord/blob/master/proxy/src/main/java/net/md_5/bungee/BungeeCord.java#L349 https://github.com/SpigotMC/BungeeCord/blob/master/proxy/src/main/java/net/md_5/bungee/BungeeCord.java#L376 https://github.com/SpigotMC/BungeeCord/blob/master/proxy/src/main/java/net/md_5/bungee/BungeeServerInfo.java#L183 https://github.com/SpigotMC/BungeeCord/blob/master/proxy/src/main/java/net/md_5/bungee/UserConnection.java#L363 All these can be replaced with channel factories.

my suggestion to natives is to do what we did to packet initialisation - replace reflections with suppliers. same for channel initialisations - use channel factories rather than initialising channels with reflections. however, most good improvements never come true in bungeecord or in spigot due to people like caoli5288 or md_5. I'm even amazed md_5 accepted the change of replacing packet initialisation from reflection with suppliers!

Please reduce your personal attacks. It's meaningless.

no no it's not meaningless. I want to tell the truth to the people who read the issues. THIS IS THE TRUTH. We're not in the java 7 era. there are a lot of improvements which can be done, particularly what people like @Janmm14 did in #3114 . "Oh it doesn't make a change, why should we change it" YES IT DOES. A direct example - what protocollib did with their char replacer stuff. Instead of replacing placeholders with patterns, they did it char by char. and it sped up stuff a lot. for such plugins, even a millisecond more and stuff can go kaboom. it's the same for bungeecord. it should be reliable and should handle lots and lots and lots of players. yet it can't. because it is coded for java 7 and with fundamental flaws. c'mon, we're in java 16. there is 1 proxy alternative which exists and it is much better, but am not going to reference it cuz mr. madman from australia will delete my comment because you can't share much in bungeecord's issue tracker and spigot as a whole. these are the primary reasons people created forks and even rewrite stuff.

Janmm14 commented 3 years ago

I think you should test and benchmark first instead of opening an issue and quote what I said. Right?

My intention is to discuss possible options, not to make a formal proposal, which requires more rigorous test data rather than a conversation.

Since we don't have discussions feature here, an issue is a great way to discuss changes before attempting to implement. I created this issue to not have it lost in other conversation.

Unfortunaly I don't have much knowledge with C/C++ build tools / lib usage, so I created this for someone else to look into it.

caoli5288 commented 3 years ago

there is 1 proxy alternative which exists and it is much better, but am not going to reference it cuz mr. madman from australia will delete my comment because you can't share much in bungeecord's issue tracker and spigot as a whole. these are the primary reasons people created forks and even rewrite stuff.

@MrIvanPlays Can you stop your attacks? It doesn't make your words any more powerful.

Yes md-5 is very cautious in accepting PR. If you want a fork, do it. No one can stop you from doing it.

The reason I object to that PR is that it changes a lot of things, but brings a performance improvement of perhaps less than 0.1%. In fact, I don't see Eventbus need to be improved in my jprofiler. It's not an hotspots.

Janmm14 commented 3 years ago

@MrIvanPlays I don't see reflection in channel initialisation?

https://github.com/SpigotMC/BungeeCord/blob/master/proxy/src/main/java/net/md_5/bungee/BungeeCord.java#L349 https://github.com/SpigotMC/BungeeCord/blob/master/proxy/src/main/java/net/md_5/bungee/BungeeCord.java#L376 https://github.com/SpigotMC/BungeeCord/blob/master/proxy/src/main/java/net/md_5/bungee/BungeeServerInfo.java#L183 https://github.com/SpigotMC/BungeeCord/blob/master/proxy/src/main/java/net/md_5/bungee/UserConnection.java#L363 All these can be replaced with channel factories.

Thanks, PR submitted.

my suggestion to natives is to do what we did to packet initialisation - replace reflections with suppliers. same for channel initialisations - use channel factories rather than initialising channels with reflections. however, most good improvements never come true in bungeecord or in spigot due to people like caoli5288 or md_5. I'm even amazed md_5 accepted the change of replacing packet initialisation from reflection with suppliers!

Please reduce your personal attacks. It's meaningless.

no no it's not meaningless. I want to tell the truth to the people who read the issues. THIS IS THE TRUTH. We're not in the java 7 era. there are a lot of improvements which can be done, particularly what people like @Janmm14 did in #3114 . "Oh it doesn't make a change, why should we change it" YES IT DOES. A direct example - what protocollib did with their char replacer stuff. Instead of replacing placeholders with patterns, they did it char by char. and it sped up stuff a lot. for such plugins, even a millisecond more and stuff can go kaboom. it's the same for bungeecord. it should be reliable and should handle lots and lots and lots of players. yet it can't. because it is coded for java 7 and with fundamental flaws. c'mon, we're in java 16. there is 1 proxy alternative which exists and it is much better, but am not going to reference it cuz mr. madman from australia will delete my comment because you can't share much in bungeecord's issue tracker and spigot as a whole. these are the primary reasons people created forks and even rewrite stuff.

I see the issues with project management but I decided to stay positive and just create the PRs and put in a little reminder here & there if md-5 doesn't respond. I am not even actively using BungeeCord anymore, but I like the software in general and want to support the original.

If you filter PRs for created by me there are also 2 rather old ones not yet merged.