Use iterators instead of recreating array in the map/filter/etc... #47
Assignees
Labels
type: performance
this merge request is about optimization
Comments
klesun
added
status: actually not closed
type: performance
|
Apparently (paste here your laugh) iterators are disposable. This conflicts with the I believe the I also have this Another problem is that each expression gets cached upon resolution, but iterator can't be cached since it is disposable. An option, I guess, is to use my |
|
Rest things in the TODO list:
|
|
There is a bug in master: $wetrParsed = SabreTicketParser::parse($wetrOutput);
$isVoid = function($seg){return $seg[''];};
if (Fp::all($isVoid, $wetrParsed['segments'])) {Attempts to get completion on .wap(ctxs -> It.cnc(
ctxs,
Tls.ifi(areInSameScope(fieldRef, assPsi), () -> list(ctx)),
Tls.ifi(!ctxs.has(), () -> list(implCtx))in the (did not happen before iterator changes for your information) (I still suspect the It.cnc, but some exploration makes me think that actual reason is that depth limit does not work anymore thanks to iterators (it was applied statically in SearchCtx)) Fixed in 6ce1bb3 |
|
Another exception below, happens here: $faRecs = $this->getCurrentPnr()->getParsedData()['parsed']['tickets'] ?? [];
$faRecs[''];Note that everything works ok here: (when you ask for completion of the element keys, not array keys) $faRecs = $this->getCurrentPnr()->getParsedData()['parsed']['tickets'] ?? [];
$faRecs[0]['']; |
|
Another one: $ticketInfo = (new GalileoRetrieveTicketsAction())->execute();
foreach ($ticketInfo['tickets'] as $ticket) {
$ticket['']; |
|
Exceptions above are resolved |
|
New problem: $lfParsed = LinearFareParser::parse($lfOutput);
if (!empty($lfParsed[''])) { |
|
Another one: public function execute(ApolloPnr $pnr, int $absPaxNum): Result
{
$nameNumber = $pnr->getPassengers()[$absPaxNum - 1]['nameNumber'];
return $this->getStoredPricing($pnr)
->flatMap(function($fareQuoteInfo) use ($pnr) {
return static::wrapExc(function(){}, [$fareQuoteInfo['']]); |
|
exceptions above fixed: 4417935 |
|
Weird completion: This is caused by depth limit being virtually ignored. Key resolution gets in a recursive loop. Should create a context for each expression to deal with that as described above... Or maybe store depth limit in |
|
|
Repository owner
deleted a comment from
klesun-misc
Oct 3, 2018
Repository owner
deleted a comment from
klesun-misc
Oct 3, 2018
Repository owner
deleted a comment from
klesun-misc
Oct 3, 2018
|
0ad770c brings the feature, each option is now displayed the moment it was calculated instead of waiting for complete resolution. But it hangs for some reason in the Laravel project on this: $battle->competitors->first()->rounds_won;Possibly because one of places where |
|
Another problem: $retrievalResult = static::combineLinkedFields($retrievalResult);
$retrievalResult['reservation'][''];If you ask for completion here it takes about a second instead of 10 ms. Possibly something triggers the full type resolution like It happens because plugin spends a lot of time determining the string value of Upd.: fix here - 535f1a4 |
|
Looks like used key completion stopped working after recent changes...
|
|
Lol it suggested only the options that are already present in array instead of all but the present |
|
I guess this can be counted for done. I don't work in RBS anymore so I can't test complex nested array constructions anymore. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Should help with the #43
This should drastically increase performance, but raises some issues. I'll describe them here and list possible solutions.
The text was updated successfully, but these errors were encountered: