On Tue, 24 Jan 2017 11:25:28 +0100 "Enrico Weigelt, metux IT consult" <[email protected]> wrote: > > I am not sure what you intend here that is different from the current > > implementation. > > Better performance.
Always the performance... for the nth time, show me that it is a problem! > I've seen that abilities are checked a lot, and > the current implementation isn't particularily efficient. In > FeatureContainer I've already optimized hasAbility() to do direct > lookup in the set(s) and bail out as fast as possible (w/o going > through getAbilities()). Which will break any class (e.g. Unit) that needs special handling and relies on hasAbility calling the overridden getAbilities. > > Also, I have reviewed the first 50 or so of your patches. I do not > > understand your objection to Streams. > > It is sloooow and memory intensive. Your evidence remains absent. > Just look at the jdk source, what > happens behind the scenes. Their streams api is bloaty and slow by > design, they I do not doubt that the implementation is krufty. Its new code after all. But, once again, and I am getting sick of repeating this, show me where FreeCol is being hurt by this. I have some rough numbers. Your turn. > And it requires jdk8, which I have on none of my production machines, > running stable/lts distros (and properly packaging that monster is a > magnitudes larger job). Sorry. Java8 is not negotiable. Java7 is no longer getting security updates. > In the long run, I'd also like to get it running w/ AOT (to get the > real performance boost), as well as Dalvik. Again the performance... However I admit porting is interesting. > > Nearly all the patches removing Streams use bloat the code. > > Note quite, a few of them do (yes, eg. finding list elements by min or > max on some attribute could be written more elegant. I think you will find the majority of them do, although you are correct that many are fairly minor. Nevertheless, there are also many that are significantly bloating. If you want to claim your code is "more expressive" I would expect it to be shorter. It is not. It *is* more "explicit" in that you are correct that the types are more obvious, but I do not consider that an advantage over being succinct. >>[Replacing] > Maybe you've just replaced even more inefficient code. Not by much I am sure. Mostly your patches just put things back to something very similar to what was there. Check the git record if you like. > > This is obviously not > > definitive as a lot of other code went in at the same time, but certainly > > suggestive that Streams have negligible impact, and even if Streams are > > fully to blame for the change, I am *not* worried that it now takes 7 AI > > players 5.2s to move rather than 5.1s. > > On my site it's magnitudes smaller. Haven't looked at the whole AI area > yet, my next 2do is the startup, which still is uncomfortably slow ... So *what* exactly is "magnitudes smaller"? I keep asking you to substantiate your claims that performance both better and important. Please explain precisely what you are measuring and why it matters. Good luck with the startup. However I expect you will find that most of the time is I/O, sending the XML for the Game to the client. Cheers, Mike Pope
pgpPES2eqG2Iz.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Freecol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freecol-developers
