On 13.02.2017 15:06, win...@genial.ms wrote:
> Hello,
> 
> you know how that answer feels? 

Like talking to an old kernel hacker, who's used to cope with many
and large patch queues and therefore tries to get around w/ minimal
bureaucracy ? :o

Having to create tickets and copy-paste patches on some website
manually, introduces lots of extra bureaucracy. And if we wanna
discuss about them, it gets even more bureaucratic - compared with
simple and efficient tools like email. It doesn't even make applying
easier - OTOH, git can apply emails (and whole mailboxes) automatically.

> Like you only value your own time, as you don't even invest enough
> of it to write a tiny justification for each patch.

Actually, I did, where I felt that it's not obvious.

Looking at the repo history, it doesn't seem that the committers there
seem to care much.

OTOH, many commits there dont seem to be very consistent: eg.
introducing temporary hacks or even breaking things, which are cleaned
up again by later commits. Those things I'd really like to prevent,
by cleaning them up before.

So, can you imagine, how it feels, being critized about things that the
committers are doing even worse ? Do you think that's how free adult
people should treat each other ?

By the way: maybe it's just a language problem, but the term
"justifications" sounds a bit like being tackled by a supervisor or a
judge. Obviously, we're all free men here, and nobody here has to
justify himself for another.

> Then it costs others about twice as much time to figure out
> what to do with such a patch, cause of reverse engineering the reasons
> you made it from the code, before verifying it actually works.

If you've got any questions, please ask.

> I still saw no numbers from you as to how much cpu time these supposed
> optimization patches would conserve, and I suspect its because you
> still did not profile. 

Actually, I did a few profilings, but it's hard to get any useful
numbers, as the jitter is just too high, and it's just not worth
the effort und patch-by-patch basis.

OTOH, as an seasoned sw-engineer w/ >25yrs experience (who also used
to build its own computers, aeons ago), I might have some piece of
understanding, whats going on under the hood and so dont need to
measure every single piece.

> That means we'd have to take the time to profile
> and most likely see no significant improvement to justify changing
> the code.

Why do you need to do that ? Did I ask you to do that ?

For most of my optimization patches it should even be obvious that they
bring some improvements (whether it's actually noticable in an
individual case is a different story), for anybody who knows a bit
about java and jvm.

Lets take a simple but common example:

--- a/src/net/sf/freecol/common/model/Europe.java
+++ b/src/net/sf/freecol/common/model/Europe.java
@@ -386,7 +386,8 @@ public class Europe extends UnitLocation
         Player player = getOwner();
         Market market = player.getMarket();
         int price = 0;
-        for (AbstractGoods ag : transform(goods,
AbstractGoods::isPositive)) {
+        for (AbstractGoods ag : goods) {
+            if (!ag.isPositive()) continue;
             GoodsType goodsType = ag.getType();
             // Refuse to trade in boycotted goods
             if (!player.canTrade(goodsType)) {

The original version does a lot of extra things under the hood, eg:
* creates a new list (where the filtered elements put it)
* creates two stream objects (plus several internal ones, eg.
  splititerator, etc)
* creates a collector object (plus several internal ones)
* creates a callback object, which is called or for each list element,
  just to call AbstractGoods.isPositive()
* collect() finally calls (though a huge stack of indirection) through
  the whole stream/splititerator chain, down to the predicate and the
  collector objects, for each list element, until the end of the
  stream is reached.

OTOH, my version skips that all away, just direct invokestatic to
AbstractGoods::isPositive() (which is easily inlinable, BTW) and
conditional jump.

Oh, BTW, my version is also using *less* code and is easier to read.

> Then if I would decide on using such a patch I personally would need to
> copy the text from each email out into a new file and try to apply it.

You could just save the mail as is and apply directly:

https://www.kernel.org/pub/software/scm/git/docs/git-am.html

> You could just post a link to a branch on your SF or Github fork and
> if its just a whole stack of related commits one posting including
> a link to a git repository and a few numbers would be better than
> a stack of emails.

Already did so, nobody seemed to care.



--mtx

------------------------------------------------------------------------------
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
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Reply via email to