search

ProtocolSupport / ProtocolSupportPocketIssues

Issue-tracker for ProtocolSupport pocket edition.
6 stars 0 forks source link

tab completion takes extreamly long #103

Open WesleyVanNeck opened 5 years ago

WesleyVanNeck commented 5 years ago

Describe the bug Describe the bug as clearly as you can. If you get any errors in the console or the client paste them on https://hastebin.com/ and link them here.

How can we reproduce the issue? Steps to reproduce the behavior:

  1. Join with PE '1.10'
  2. Do 'type a command or do just /'
  3. See the issue

Expected behavior instant command list our a smaller wait time XD

Screenshots If applicable, please attach screenshots of both the Java and Bedrock edition of the game.

What version of ... are you using? ps bungee (yesdog) latest and latest mcpenew client 1.10

Additional information am using protocollib but thats for one plugin that doesnt have commands or does somting with it, ...)

djacks6278 commented 5 years ago

change spigot.yml option

tab-complete: -1

this solution will be work nice

WesleyVanNeck commented 5 years ago

@magicus I think this prio is high and it isn't a visual glitch

Shevchik commented 5 years ago

Blame pe for doing it way too slow.

WesleyVanNeck commented 5 years ago

blamemojang #blamePE

magicus commented 5 years ago

I agree with Shev. It's hard to do anything about; apparently PE has some non-linearity in how it handles their data structures. Possible fixes includes: 1) Disabling tab completion altogether 2) Disabling tab completion completely if the number of commands pass a certain limit 3) Arbitrarily dropping commands from tab completion after a limit 4) Trying to merge the expanded PE "command node chains" into the more compact "nodes with alternatives" that PE seem to use internally, in the hope that this improves performance.

None of the solutions seems particularly attractive. The option 4 seems like the only chance to have a really desirable result, but we don't know if it will work, and going there will require quite a bit of complex algorithms -- which in worst case will have an unacceptable performance cost at the server. It wouldn't surprise me if such merging would end up at O(n^2) or above, and then we'd just shift the penalty to the server.

magicus commented 5 years ago

There is a work-around suggested above, which is basically 1), but as an option you can select yourself. I can't seriously think of a much better way to handle this.