nep a écritIl faut compter le nombre de hoopers par lequel passe un item pour le lag, chaque item passe toujours par tous les 14 (respectivement 9) hoopers ici ?
Dans les deux systèmes (silo actuel et mon silo léger), les items passent dans tous les hoppers : c'est juste un "empilement" de coffres avec des hoppers entre.
Le silo XL (et les silos de la banque) fonctionne à peu près de la même façon, sauf que les flux d'items sont répartis en plusieurs "sous-empilements" de coffres, qui se séparent en haut et se rejoignent en bas.
Ceci dit, il y a un petit couac dans ton raisonnement. En théorie, si c'était bien codé tu aurais raison, mais dans la pratique faut pas oublier que le code derrière c'est du Mojang. 😛
Sur ma machine, un hopper prend en moyenne 10µs à faire sa mise à jour de TileEntity (à chaque tick, soit toutes les 50ms),
mais c'est à vide, quand rien ne se passe (d'ailleurs, je ne vois pas de différence quand il y a des items qui passent). Donc items qui passent ou pas, le simple fait d'avoir un hopper posé là augmente la charge serveur.
D'ailleurs fun fact : les 10µs c'est une moyenne, la fourchette varie de 20µs à 1µs selon les hoppers (dans le cas des silos, tous vides). Et les mêmes hoppers connsomment toujours la même chose, même en refaisant les tests plusieurs fois. Mais quand je vais voir celui qui bouffe le plus, que je le brise et que je le replace, ben il consomme plus du tout la même chose. ^^
D'où l'utilité des benchmarks dans ce genre de cas.
nep a écrit
Expérimentations avec benchmarks, précision < à la dizaine de µs, j'en salive de plaisir. Formidable !
😀
Les benchmarks, y'a que ça de vrai !
Merci Opis ! 😀
nep a écritOk mais si c'est juste ça, comment on arrive à gagner des hoopers avec autant de coffres ?
J'ai pas tout compris la question je crois. ^^
Tu veux dire comment j'ai fait pour réduire le nombre de hoppers de 14 à 9, en gardant le même nombre de coffres ?
