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

Why roll up world into esper module? #95

Closed
sb3rg opened this issue Nov 15, 2023 · 4 comments
Closed

Why roll up world into esper module? #95

sb3rg opened this issue Nov 15, 2023 · 4 comments
Labels

Comments

@sb3rg
Copy link

sb3rg commented Nov 15, 2023

I am curious the reasoning behind why worlds were rolled up into the esper module? In working with this library and encountering this breaking change, I feel like I have to think a lot harder about this hidden context where as before it seemed much more explicit? Perhaps I am not thinking of world appropriately, which is why I feel the need to ask. Can you help me understand the reason behind the change? Perhaps it's my approach that hasn't been keeping in tune with the philosophy and design intent.

@sb3rg sb3rg added the question label Nov 15, 2023
@benmoran56
Copy link
Owner

Hello Sean,

This thread here was the initial spark for it: #87
The main driver for me was the improved performance, rather than getting away from OOP.

How many worlds are you using in your project? In my own, I tend to use only one world per game scene. That doesn't add much complication, because the context switching happens at the same time the scenes are changed. If I can understand your use case, perhaps we can find a solution to simplify things.

@sb3rg
Copy link
Author

sb3rg commented Nov 21, 2023

Thank you for pointing me in the right direction and bringing me along the thought process. I will refactor my code and try the new approach. It may very well end up cleaning up all of the floating world references. For my project, I am dealing with a lot of events and event data is much more transient vs needing to be transformed en masse by a processor. I will report back and see if the new approach makes it simpler for my use case, but I don't know as of yet.

@sb3rg
Copy link
Author

sb3rg commented Nov 30, 2023

So, in advancing my package towards incorporating 3.0 without an explicit "World," I noticed one big difference.

Because I have so many events that drive my design, I was using Worlds to dispatch process calls for those events. This is because I don't want all registered processes to execute when a certain type of event occurs. Therefore, I created these single responsibility worlds to handle these one-off events.

I realize that of course you have an event dispatch system available, but I was avoiding using it because it was about an order of magnitude slower than just creating a special purpose world and handling those particular events by calling process on them.

Now that I don't have explicit worlds, I am coerced towards using the event dispatching system (or so it seems). And when I migrated some of my code for testing the system performance decreased by about 40%.

I guess I could use the explicit call to "switch_world" to try and get back to my previous more performant version that side-steps the event system, but that feels clunky. Perhaps there will be a more performant event_dispatcher on the horizon? That way I can maintain my performance goals while adhering to 3.0 implicit worlds paradigm?

@sb3rg
Copy link
Author

sb3rg commented Dec 8, 2023

Marking closed given responses here: issue96

@sb3rg sb3rg closed this as completed Dec 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants