On Tue, Apr 26, 2016 at 05:43:16PM +0200, Javier Loureiro Varela wrote:
> Normally, it is easier to optimize the algorithm and the data structures
> (specially data structures)
Ack, wasted time for a post, you said the same thing I meant :P
As for the Intel vs ARM, in the past I had a Intel vs AM
On Tue, Apr 26, 2016 at 11:07:52AM -0400, Chris Pavlina wrote:
> These are very, very small numbers. Honestly, is it worth the added code
> complexity? The added chance of bugs? (None here that I can see, but it's a
> risk we take every time we allow something like that). For a 3% improvement in
>
---
3d-viewer/3d_material.h| 3 +++
3d-viewer/3d_struct.h | 2 ++
common/base_struct.cpp | 7 ---
eeschema/class_libentry.h | 6 ++
eeschema/class_sch_screen.h| 3 +++
gerbview/class_gbr_screen.h
This is a good point. A test like this isn't particularly enlightening, which
is why I didn't bother with updated numbers after realizing my mistake. They
don't tell much.
Really the important bit is whether things are improved *in the operating
code*, and as far as I can tell, they are not - unle
I was a vfx render engine engenieer for years, and I can tell you that it
is really easy to mess up things with "optimization". I didnt check the
code for this particular case, but a simple test with a loop is not enough
to tell you if an optimization means something.
- It can make the funcion siz
Okay, the numbers aren't quite so nice. I posted the wrong ones and now have
egg on my face. That's what I get for playing around with git too much.
I still stand by what I said about needing to show improvement, though. While
the new code *does* improve things by about 15% on my computer when I r
Hi,
I hope I don't sound ranty - but really, I think we need to put in place some
policy about well-meaning but ineffective optimizations. They're one of the
quickest ways to screw up maintainability and introduce the possibility of
errors.
I strongly suspect 6711 "Optimize VECTOR2::Rotation for
7 matches
Mail list logo
