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

Allow TaskDriverSystem Jobs to be able to write to another system and preserve the context #246

Open
jkeon opened this issue May 10, 2023 · 2 comments

Comments

@jkeon
Copy link
Member

jkeon commented May 10, 2023

TaskDriverSystem jobs are able to Resolve back "UP" the chain to a specific context TaskDriver.

Ex.

TimerTaskDriverA
TimerTaskDriverB
TimerTaskDriverC
TimerTaskDriverSystem

The System executes jobs that run on instances that came from A, B and/or C and when complete, will write that complete back to the correct A, B or C complete stream.

Sometimes we want to be able to kick the result of that System job "DOWN" the chain to another System or another TaskDriver that is a child of A, B, C.

Assume that A, B, C had some sub-task driver each of MoreProcessingD, MoreProcessingE, and MoreProcessingF respectively and was governed by a MoreProcessingSystem.

Today, we need to get the result from TimerTaskDriverSystem and write to TimerTaskDriverA::TimerComplete and then have a job that kicks off that to write into MoreProcessingSystem via MoreProcessingD.

We'd like to be able to bypass that and have TimerTaskDriverSystem write directly to MoreProcessingSystem and know the context is MoreProcessingD by virtue of it being the sub-taskdriver of TimerTaskDriverA.

We should be able to do this by building the lookup of targets based on the new DataTargetIDs.

@mbaker3
Copy link
Member

mbaker3 commented May 10, 2023

What does this get us? Reduced instances where we have to wait 1 frame? Or is this just a performance optimization?

@jkeon
Copy link
Member Author

jkeon commented May 17, 2023

In the example:

  • Write to SystemA from TD1
  • Resolve to TD1-CompleteFromSystemA
  • Write to SystemB from TD1 based on TD1-CompleteFromSystemA
  • Resolve to TD1-CompleteFromSystemB

We have 4 frames to execute the whole thing, with 4 jobs and 4 data streams.

Whereas we could do:

  • Write to SystemA from TD1
  • Write to SystemB from SystemA
  • Resolve to TD1-CompleteFromSystemB

And everything drops to 3.
25% reduction across memory usage, code authoring and maintenance, and frames waiting.

As the chain increases in nesting, Navigate->FollowPath->Move for example, that compounds. We don't need the intermediate step jobs and data streams that only exist to pipe data down.

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

No branches or pull requests

2 participants