Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[READY] I at overhaul MK II #10370

Merged
merged 20 commits into from
Dec 22, 2014
Merged

Conversation

kevingranade
Copy link
Member

This implements BevapDin's suggestion of a wrapper class that allows callers to modify items on the map easily without exposing direct access to the underlying container.
It got completely out of control, now each submap and vehicle maintains a list of iterators to their active items and iterates across that instead of across every item.

fixes #9917
Addresses some of #10269 (shouldn't trigger auto-close of the other issue)

@kevingranade kevingranade added the (S2 - Confirmed) Bug that's been confirmed to exist label Dec 7, 2014
@kevingranade kevingranade changed the title I at overhaul MK II [WIP] I at overhaul MK II Dec 8, 2014
@kevingranade
Copy link
Member Author

Found some bugs, boo.
Specifically I messed up building rotation.

@kevingranade kevingranade added in progress and removed (S2 - Confirmed) Bug that's been confirmed to exist labels Dec 8, 2014
@kevingranade
Copy link
Member Author

Fixed building rotation and tiles builds, but I want to hold off for more testing before marking this ready to go, I'll probably just push on to adding the active item optimizations then test that a lot.

auto map_items = i_at(x, y);

int i = 0;
for( auto iter = map_items.begin(); iter < map_items.end(); iter++ ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This loop does not seem to change i, the condition i == index will never be fulfilled except when the first item is to be erased.

@kevingranade
Copy link
Member Author

There are still some bugs here, and I need to rebase, but this is getting VERY CLOSE now.

@kevingranade
Copy link
Member Author

Sole remaining issue, I totally hosed radio item processing. I'll give it the same treatment as active items. It should be easy now that all the infrastructure is in place.

@kevingranade kevingranade changed the title [WIP] I at overhaul MK II [READY] I at overhaul MK II Dec 21, 2014
@kevingranade
Copy link
Member Author

Actually tested radio controlled items, and while their performance hasn't been enhanced like active items, they are still functional, so I'm going to call it there. Rebase incoming, which should be good to go.

@KA101
Copy link
Contributor

KA101 commented Dec 21, 2014

KA101 debugports to Berlin

@KA101 KA101 self-assigned this Dec 21, 2014
@KA101
Copy link
Contributor

KA101 commented Dec 21, 2014

OK. So far, takes about a wall-clock second per DDA minute to long-action or sleep. Got an evac shelter full of active crap (chunks of meat, tainted/OK, melons, lightstrips) and some non-active stuff (Linux t-shirts, logs). Scent is on, doors are boarded.

Long-actioned and slept downstairs, free of active items: long actions were completed in about 5 seconds and sleeping took three seconds to process half an hour: roughly 10x faster.

Sorry, Kevin. :'-(

@KA101 KA101 removed their assignment Dec 21, 2014
@kevingranade
Copy link
Member Author

How's that compare to before the change? We're not talking infinite speed here, just a speedup.

@KA101
Copy link
Contributor

KA101 commented Dec 21, 2014

I know. Not much of a speedup on this end: at best, marginal lag reduction in walking around and elimination of an additional lag burst whenever lying down to sleep. :-/

Long actions in the master (before your merge), with items, about 1:1 wall-second:DDA minute, but with a five-second lag between hitting A and DDA acknowledging the action. Sleeping with items, 10-second lag to lie down, then 30-33 seconds per half-hour cycle with distinct pause for updating sound marks, then updating clock and character status.

@kevingranade
Copy link
Member Author

Ok, the tests where it was showing the most benefit had relatively small amounts of active items (e.g. rotting food) nearby, and relatively large amounts of inactive items, I'm guessing you're testing with the opposite. I don't know for sure which is more typical, but the case where there are not that many active items shows a gigantic benefit here.

There's an additional change I'm planning on making to specifically target rotting food, but this all is a precondition for it anyway. If your testing indicates this works correctly, please consider landing this, and I can pick up from there for the next set of changes.

@KA101
Copy link
Contributor

KA101 commented Dec 21, 2014

Yeah, it's the opposite here, thousands of active items processing away. Had somehow thought you'd managed to secure 'em en masse.

8,000 charges of melon is not typical (100 each tainted/OK meat might be), so yeah. I'll give this a final test-compile and merge it.

@KA101 KA101 self-assigned this Dec 21, 2014
@KA101 KA101 merged commit ee87a4b into CleverRaven:master Dec 22, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Swap out item vector for a std::list.
3 participants