Closed altrisi closed 3 years ago
where do you get the loading info?
Output viewer (in this case from Eclipse)
ah
It should also appear in Vanilla/MultiMC viewer
ye. woudl you mind seeing more or less after exactly which commit it increased?
The problem is that history here is not linear, which means that commits from a PR can be mixed within commits of another PR.
(BTW, I'd recommend when merging, using Rebase and Merge, so commits get added to the top and not in this weird order, history becoming linear. You could also squash, but then you lose some info).
Although I think this is because of the write_file() call on initialization (it wasn't there before, not sure though). Does Scarpet allow writing files async?
I don't see why it shouldn't, according to what I found when writing the JSON PR (file IO has a general lock which I don't see why it should be thread-specific). But I'll wait for a response just in case.
Although I think this is because of the write_file() call on initialization (it wasn't there before, not sure though).
no, cos the write_file() call on initialisation is called only occasionally, even on the version that you posted in the issue desc
True, don't know how I read that.
Can you rebase when merging a PR in github?
There is a drop-down next to the merge button where you can select the merge mode.
could the long load time be due to like 38kb freaking size?
and complex handling of help function at load?
ok, maybe more the sheer amount of code than the file size, but still.
and complex handling of help function at load?
I also thought the command map processing could be the cause, but the previous state compared here also has it. It is only about 5-20ms (according to my testing in that time).
And I don't think that only the new code presence would increase it that much, since we are comparing with one with 800 lines, the current one being around 960. If it was related to the quantity of code, I think it would be more linear.
Maybe the command registration?
I noticed that I was running _parde_config
for global_Default_lang
for every single language. After taking it outside, and only running it once, I brought load time down to ~1100 ms.
Command: reduce([range(100)],_a+profile_expr(_parse_config(global_default_lang)),0)/100
(high is better)
FIRST CODE:
_parse_config(config) -> (
if(type(config) != 'list', config = [config]);
ret = {};
for(config,
if(_ ~ '^\\w+ ?= *.+$' != null,
key = _ ~ '^\\w+(?= ?= *.+)';
value = _ ~ str('(?<=%s ?= ?) *([^ ].*)',key);
ret:key = value
)
);
ret
);
SECOND CODE:
_parse_config(config) -> (
if(type(config) != 'list', config = [config]);
ret = {};
for(config,
key = (t=split('=',_)):0 - ' ';
value = join('=',slice(t,1))~' *([^ ].*)';
if(key && value,
ret:key = value
)
);
ret
);
I can't understand why the execution time of the function 100 times is about the same, but the profile_expr()
functions rates the second one much better compared to the first one...
Can't believe it but I found it!
It gets down to almost nothing by commenting line 497! https://github.com/Ghoulboy78/World-edit-scarpet/blob/0d0bbf037a891b4997673b370c4ea2d6ea22bf84/world-edit.sc#L485-L497
What does that _permutation
function do so slowly?? 1500ms by being called once!
Added in b48dcfe8fbf6e5df4546c4c8c445ead5daa1c0cb. Why is it recursive?
Oh... I see...
There must be another way...
we thought abt it, but we couldnt find solution...
Am I right by supposing that finds every possible combination for the flags suggester? Or what does it do?
ye thats what it does
we werent sure abt the best way to do it tbh...
PR coming soon
PR with a fix ready
Am I right by supposing that finds every possible combination for the flags suggester? Or what does it do?
I think we used it to validate the input. It should not be difficult to find another way: You can check which flags already wrote and suggest all the missing appended to the current parameter.
Right after merging the help menu PR, (copy of that state at https://hastebin.com/fomikikeze.js, misses some changes but mostly that), loading times were of about 250ms.
In the latest commit, loading times are about 1500ms (yes, 1.5 seconds, 6 times as much)