fix: Warm up Orchestrator build cache from previous Composer session #6550
Conversation
taicchoumsft
requested review from
a-b-r-o-w-n,
beyackle,
boydc2014,
cwhitten,
GeoffCoxMSFT,
hatpick,
srinaath and
tonyanziano
as code owners
taicchoumsft
changed the title
taicchoumsft
changed the title
| ); | ||
|
|
||
| return modelData.model && snapshotData.length | ||
| ? await Orchestrator.getLabelResolversAsync(modelData.model, '', new Map(snapshotData), false) |
There was a problem hiding this comment.
I assume this matches the lu object id "f.replace('.blu', '.lu')" pass in the buildAsync method, correct?
There was a problem hiding this comment.
Yes, these are also the ids we get back from the results object from buildAsync,
…microsoft/BotFramework-Composer into tachou/orchColdBootOptimization
|
By code session, we mean, maybe it was closed before, right? If for a hot session, we will just memorize that in memory, is that correct? |
Yes, that is right. This cache warmup is only for when user has trained Orchestrator in a previous session, then closed Composer, then re-opened it. If the user is in the same hot session, we use the existing in-memory cache logic. |
|
Tested it and LGTM |
…icrosoft#6550) * Update orch package * initial implementation * Tighten up code and exception handling * Unit tests * Fix linter errors * Don't rethrow error for cache - safe to continue on * Fix build error of worker script when testing Co-authored-by: Dong Lei <[email protected]>
Description
If there are embeddings (in
.blufiles) from a previous Composer session, we can use them to warm up the OrchestratorLabelResolversCache. This dramatically speeds up subsequent build times in a cold Composer session.If Orchestrator isn't used, the warmup does nothing.
Task Item
closes #6481