Thread history
Viewing a history listing
| Time | User | Activity | Comment |
|---|---|---|---|
| 08:23, 21 July 2013 | Skilgannon (talk | contribs) | Comment text edited | |
| 08:23, 21 July 2013 | Skilgannon (talk | contribs) | New reply created | (Reply to Re: "pointer stack instead of object stack") |
| 03:00, 21 July 2013 | MN (talk | contribs) | New reply created | (Reply to Re: "pointer stack instead of object stack") |
| 22:45, 20 July 2013 | Rednaxela (talk | contribs) | New thread created |
So that change had a positive effect when you benchmarked it? I'd tend to call "pointer stack instead of object stack" an inaccurate way of thinking about it, because object references in Java are pointers under-the-hood.
I have a feeling that perhaps the performance gain you may have saw actually came from avoiding a pointer deference in "if(results.peekPrio() > pointRectDist((2*_dimensions)*nodeIndex,searchLocation))" as compared to "if(results.peekPrio() > searchNode.pointRectDist(searchLocation))"
Calls to private methods are inlined. Calls to public methods aren't. Object references and polymorphism are a lot harder for compilers to optimize.
Polymorphism overhead can usually be detected with profiling.
Yeah, that's exactly where I was trying to speed things up. The way it is now, any path that I don't descend never has its Node contents examined, because I don't have to open up the Node to get the index when checking the bounds anymore. This means the Node contents (and the pointer to it) is never loaded unless it is determined that the Node needs to be searched.
Benchmarking says it's just a *tiny* bit quicker, and I like it so it stays =)
