User talk:Skilgannon/KDTree
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Optimization found | 6 | 02:46, 31 July 2015 |
Weighted Tree | 6 | 03:45, 25 December 2013 |
Re: "pointer stack instead of object stack" | 2 | 09:23, 21 July 2013 |
First page |
Previous page |
Next page |
Last page |
I found a optimization, You can use 65536 + 2*_dimensions instead of 512 * 1024 / 8 + 2*_dimensions.
Two things - actually, three:
- That code executes once, because it's in the constructor. Clarity >> saving one multiplication and one division calculation during initialization.
- The Java compiler should optimize this, making it irrelevant anyway - that is, the compiled .class file will be the exact same bytecode.
- Please spend more time writing bots and less time posting on the wiki. I'm sorry for being blunt. I've never been in this situation, but your posts are mostly inane, to the point that I sometimes wonder if you're the most successful troll I've ever encountered.
I agree with Voidious (except that I don't mind being blunt as much as he seems to). Your questions/suggestions are usually poorly researched and annoying. IIRC, the time you joined the wiki was roughly the time activity here started to die off. I can't speak for others, but personally, the frequency of your questions and the ridiculousness of the subject matter made me stop frequenting the wiki as much as I had previously. (Though in fairness, college work also had some impact, that was more in the realm of coding and less in the realm of "robowiking"). I suggest that we implement some sort of warning system (say three consecutive "ridiculous questions/suggestions") and then a temporary ban.
Thanks for adding a weighted tree, It makes me feel safer to know that my implementation does the correct thing. Where are you using it in Wintermute?
In Wintermute I have a single tree for bullet hits, but I have 3 different weighting schemes that concentrate on different types of enemies. Since they all use the same tree I just set the different weights before pulling the KNN. It could be done just as well (and probably a bit faster) by keeping different trees, but I wanted the possibility of adjusting the weights as the battle went on, even though I never ended up using it.
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 =)
First page |
Previous page |
Next page |
Last page |