One thing about modifying the iterators. I originally commented that I
thought an object there was a bit much but it helped Denis, who was
doing all the work after all, keep the code organized in his mind. I'm
not sure what kind of measurements he made, but he didn't feel that they
were hurting performance at the time. If you are finding that the
allocation of the iterators is costing us then I'd just as much like to
see that paradigm go away, though your fix to allocate them once and
then re-init them does save the memory costs.
Other renderers I've worked on an written have done essentially the same
work inline rather than farming it out to another object.
I also think it's a good suggestion to keep fixes on code like this more
focused on isolating the fix itself rather than reorganizing the code to
a personal style to fix a few issues. So, as far as the code
organization changes I agree with Clemens there. When it comes down to
"a quick fix that doesn't touch many lines of code" like your init()
solution vs. "rewriting that part of the code to no longer need the
operations that were causing problems" then it gets grayer. I would
have probably eliminated the iterators altogether because I would view
it as reducing the complexity of the code, but your solution would
probably touch fewer lines of code (if you factor out the
reorganization). I at least wanted to throw that idea out as a
suggestion...
...jim
On 4/17/13 9:52 PM, Laurent Bourgès wrote:
Hi clemens
Le 17 avr. 2013 23:16, "Clemens Eisserer" <[email protected]
<mailto:[email protected]>> a écrit :
Hi Laurent,
thanks for having some interest for my efforts !
As I got almost no feedback, I felt quite disappointed and was thinking that
improving pisces was not important ...
Glad to see work is ongoing to improve pisces's performance :)
Thanks a lot: I am working on pisces during my spare time and
congratulations is very important for my motivation.
I had a look at the patch just to be curious (I don't have reviewer status),
but to be honest I had troubles finding the relevant parts.
I agree I modify the code to help me understanding it : @override,
grouped fields, constant first, debug logs ...
I can revert most of these boilerplates ... during cleanup.
I sent the patch as webrev to let other people evaluate its performance
using their own platform, work load, benchmarks ...
Having not followed the discussion that closely, it was almost impossible for
me to extract the real modifications from boilerplate/refactoring as your patch
weights almost 3000 modified lines.
I looked at the webrev and I advocate I can discard many line changes.
As I use netbeans, it modified the code so easily... nevermind.
I am just an intrested observer without any official state, yet personally I
would prefer smaller pieces with clear description/title.
However, I wouldn't want to cause you additional work and it's just a single
opinion.
Ok. I mainly modified memory handling: use a renderer cache to reuse
arrays and pisces class instances to avoid too much allocations and
resizing ... stored in thread local or concurrent queue.
Thanks for working on pisces!
Thanks for your feedback too.
Laurent
Regards, Clemens
