Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Biography Text, Album Info, Picture. www.last.fm (Read 73247 times) previous topic - next topic - Topic derived from Re: WSH Panel Mod scr...
0 Members and 1 Guest are viewing this topic.

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #175 –
Quote from: regor on
I have +70K tracks on my library and loading time is not a problem on my side at all with Wilb script, nor this one, neither with my own which do more expensive calcs at startup than reading text files. So I don't think a large library is the answer but how the thing is coded.

It makes no sense at all that it takes 14 secs at startup when the script is supposed to just show some info from a text file for the current track. No matter how you look at it.
I have 70k files and like I said, and it is 100% the result of other processes that are happening at startup. Nothing in this script is taking 10+ seconds to load... it's just not executing. Also as soon as the slow script popup appears FSM purposely blocks script execution, but the timer keeps running so all you can say is it is taking more than 10 seconds.

An even better test than just restarting foobar is to clear the script completely. Load a different script. Close and restart foobar, then replace the other script with this one. My guess is it will take <100ms. There's no logical way you can say "well if you load it after foobar starts up it takes a 10th of a second, but if you load it while foobar is starting up for the first time in a while it takes 100x longer" and conclude that the script is doing something wrong.

The problem is NOT the script, it's what FSM is doing at startup, and that's having it's execution thread blocked for <REASONS>. The problem might be FSM, and it might just be how fb2k allows components like this to execute. @TheQwertiest might have some ideas, but I wouldn't be surprised if it's outside his control. Like I've said, there are things you can do to slice up the script loading into async pieces, but again all that does is hopefully mitigate showing the "slow script" popup, it doesn't do anything to speed up loading. In fact it'll actually slow things down a little bit (Georgia went from 150ms to 350ms load time), but again that's better than showing a popup that users have to clear.

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #176 –
I'm out of this discussion. You are making assumptions about what may be the problem, the same than me, but there is a limit... it's pretty clear the problem only appears on this script for him -on operations by this script at 2 different points- (while the rest are doing fine), which contradicts your points and <reasons>.  Neither it's a general problem by SMP since everybody's scripts don't get randomly blocked indefinitely at startup neither take +10 seconds to load due to <reasons>.

If that happens, unless SMP has a bug which magically only happens here, the most probable reason points to something coded on the script, since no operation requires waiting +10 seconds unless you are doing something really strange. Like processing the entire library, loading files for no reason on memory, opening text files which are blocked or using on_metadb_changed which also fires on startup multiple times for heavy tasks (which takes 70% loading time on my setup to do nothing)....

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #177 –
Quote from: regor on
I'm out of this discussion. You are making assumptions about what may be the problem, the same than me, but there is a limit... it's pretty clear the problem only appears on this script for him -on operations by this script at 2 different points- (while the rest are doing fine), which contradicts your points and <reasons>.  Neither it's a general problem by SMP since everybody's scripts don't get randomly blocked indefinitely at startup neither take +10 seconds to load due to <reasons>.

If that happens, unless SMP has a bug which magically only happens here, the most probable reason points to something coded on the script, since no operation requires waiting +10 seconds unless you are doing something really strange. Like processing the entire library, loading files for no reason on memory, opening text files which are blocked or using on_metadb_changed which also fires on startup multiple times for heavy tasks (which takes 70% loading time on my setup to do nothing)....
I'm sorry, but you can't reproduce this issue and I can. I have a fairly good idea of what's going on because I tested it once a day for 6 months. Take a look at my investigations into this issue from a year ago. You claim that it's hanging at 2 different points, but you have 0 proof of that. I can almost guarantee you that if he broke execution 10 times it would happen in 10 different places. It's NOT the script (other than the general size of the script... it'll never happen in short scripts). It's that the thread executing the script has paused execution for <reasons>, but FSM's slow script timer is still counting up.

You state "Neither it's a general problem by SMP since everybody's scripts don't get randomly blocked indefinitely at startup neither take +10 seconds to load due to <reasons>" but then you turn around and say it's the script's fault even though nobody else is experiencing this. Obviously the problem is outside the script and is something with the machine, the HDD state, the size of the media library, other components being loaded at startup, the OS version, etc... you know <reasons>.

You don't have to believe me (and clearly you don't since you ignore all my proof even while arguing against your own statements), but there's probably nothing kgena_ua can do to fix this short of just masking the problem. I can try and help him do that if he likes, but honestly it's probably not necessary.

Code: [Select]
// Your biotest(1).js version (10+ seconds):
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (on_metadb_changed): 18497ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87 (Georgia: Biography, Covers, Albums, Title, Similar artist, Lyrics info.www.last.fm v01052021 by kgena_ua): initialized in 20537 ms

// Reloading same after foobar has started up:
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (on_metadb_changed): 400ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87 (Georgia: Biography, Covers, Albums, Title, Similar artist, Lyrics info.www.last.fm v01052021 by kgena_ua): initialized in 425 ms
:D

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #178 –
Thank you MordredKLB for your contribution.
I thought I was the only one getting this message.
But I couldn't find anything about it in the forum.

The test with bio_test(1) gives me almost the same result as yours.

I also just want fb to run (again) without stalling and without messages.
I am only a user and have been using fb since version 0.83 (2004 ?), with various plugins. And without any problems - great work by all involved.

I hope that this problem will also be solved.

With kind regards

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #180 –
Quote from: MordredKLB on

Code: [Select]
// Your biotest(1).js version (10+ seconds):
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (on_metadb_changed): 18497ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87 (Georgia: Biography, Covers, Albums, Title, Similar artist, Lyrics info.www.last.fm v01052021 by kgena_ua): initialized in 20537 ms

// Reloading same after foobar has started up:
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (on_metadb_changed): 400ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87 (Georgia: Biography, Covers, Albums, Title, Similar artist, Lyrics info.www.last.fm v01052021 by kgena_ua): initialized in 425 ms
:D
I was not going to answer anymore, but wow. I mean, I clearly pointed to the problem...
Really man.. so you see that callback takes 18 secs on first execution but your conclusion is that it's fine. That is NOT right. No matter if it happens once every 2 times or on every startup.

Let me repeat it again. That callback (its code) does NOTHING useful on startup (since the panel is not visible neither usable until everything is loaded). And even worse, it fires multiple times on every startup (repeating the same actions for nothing). You don't have to use that callback until foobar has finished startup completely. So it is wasting 18 secs (or 400ms on second execution) for nothing, since there is nothing to display. If that's good practice coding... then I don't know what's bad coding.
(hope we can agree the biography panel has NOTHING to show when the UI has not loaded entirely yet, etc. so it should not try to process anything on that callback until startup has finished completely)

I really don't care since it is not my script, and I don't care if it's 500 secs or 400 ms. It's a freakin +90% of execution time wasted for nothing, just because the callback is being used wrong. If you simply add a boolean check on that function to return and do nothing (until a track is selected or playback changes for the first time or any other user interaction which can be associated to startup ending), magic. The problem is gone (although the entire routine should be checked since the behavior is not right). No matter if it's the first or the second execution of foobar.

But hey, you can keep discussing about the timer indefinitely. As @snotlicker shows, it can be changed to an arbitrary number to not show the message. But that doesn't change the script is working erratically, wasting time for nothing. Which is the base problem...

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #181 –
Hello regor

I agree with you there.
The script must not start until fb is fully loaded!
Basically, scripts and panels (in my opinion) should only run when they are active - inactive panels do nothing.
Increasing the counter as snotlicker showed (I had no idea that smp enters something here) only leads to the fact that no more message is displayed, but the loading time remains the same. It takes far too long. I didn't have that with jscript-panel with the same number of tracks !! that means there must have been a change in the coding, or SMP reacts differently to the coding than jscript-panel.

Maybe there is a happy ending after all

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #182 –
Quote from: lender1257 on
Hello regor

I agree with you there.
The script must not start until fb is fully loaded!
Basically, scripts and panels (in my opinion) should only run when they are active - inactive panels do nothing.
Increasing the counter as snotlicker showed (I had no idea that smp enters something here) only leads to the fact that no more message is displayed, but the loading time remains the same. It takes far too long. I didn't have that with jscript-panel with the same number of tracks !! that means there must have been a change in the coding, or SMP reacts differently to the coding than jscript-panel.

Maybe there is a happy ending after all

Check your pm. About scripts doing things at startup... well that is in fact a "limitation" (*) of SMP, yep. They are loaded at startup and it's left to the coder the way it's loaded. You can debounce, throttle, delay, wait for callbacks, async, etc. to call some routines. Panels can be running code or not independently of being active. i.e. I have some panels which add some functions called by foobar standard buttons, they would not work if inactive panels can not run code.

BUT it's obviously the coder's responsibility to not add useless code at the wrong places. A bio panel, which requires painting the info, should only be running when the panel is active, I think that's obvious... others may think different.
* Limitation because there is not a "on_startup_finish()" callback to use yet for these cases.

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #183 –
Quote from: regor on
I was not going to answer anymore, but wow. I mean, I clearly pointed to the problem...
Really man.. so you see that callback takes 18 secs on first execution but your conclusion is that it's fine. That is NOT right. No matter if it happens once every 2 times or on every startup.
Hey, we're getting somewhere now. You're almost there.

I agree with you that the callback does nothing useful on startup, but it's impossible to know when startup should end. I also probably wouldn't have coded it using on_metadb_changed, and if I did I'd check to make sure not to do anything if one of the changed handles corresponded to the metadb that's being watched, before reloading everything. Another thing that should be done at startup is to do the initial on_item_focus_change() async:
Code: [Select]
setTimeout(() => {
    on_item_focus_change();
}, 1);
That'll help slightly.

The issue as you point out is you don't know when the UI is ready, and FSM can't provide that information. So we're kind of in a conundrum aren't we?

In my setup where I can make foobar start SLOOOOW, let me show you the output of the default 120 line "click here to open editor" FSM script:
Code: [Select]
Spider Monkey Panel v1.4.2-dev+1c8cdb87 (): initialized in 886 ms
User Interface initialized in: 0:09.237594
Autoplaylists initialized in: 0:00.042363
"Has Disc subtitle" : 0:00.042348
Startup time : 0:12.509686
A script that loads in 3ms every time when reloaded after foobar has started up, takes 886ms at startup (obviously very slow) but wait... Foobar is still taking 12.5 seconds to startup because the UI is taking 9 seconds to start and everything else is basically instant. There's nothing to optimize. Nothing being wasted. Sometimes foobar is going to load very slow and it has nothing to do with the script. Now your argument is that the script is slowing the UI startup down by 886ms of that startup, but it's my contention that UI start up is essentially being paused and the script itself is not really executing at that point. The_Qwertiest seems to agree with me here as well, but I don't want to put words into his mouth. Attaching and pausing in VS2019 shows most of the time is being spent in ntdll.dll. Not sure what better JS is gonna do about that.

THAT'S why I say optimization doesn't help. Sure there are things @kgena_ua can and should change. Storing the value of remap_artist so as not to recall that function every time is a good one, but ultimately that's not the cause, it's just exposing the symptoms.

One last debug log with a slight modification of your script to better illustrate what I'm talking about (and again refactoring to not use on_metadb_changed would be much better, but that's not the point):
Code: [Select]
Startup time : 0:17.958061
>>> D:\Source\foobar2000_portable\tmp_Biography\_download\remap_artist.txt
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (artist): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (artist): 0ms
>>> D:\Source\foobar2000_portable\tmp_Biography\_download\remap_album.txt
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (album): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (on_metadb_changed): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (artist): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (artist): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (album): 332ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (on_metadb_changed): 333ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (artist): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (artist): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (album): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (on_metadb_changed): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (artist): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (artist): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (album): 0ms
Spider Monkey Panel v1.4.2-dev+1c8cdb87: profiler (on_metadb_changed): 0ms
Startup took 17 seconds, but has already finished. Then we get 4 on_metadb_changed events immediately after startup finishes. Both remap_artist.txt and remap_album.txt are 0-byte files so there's nothing to read in them. That's why every instance takes 0ms except for that one remap_album call which "inexplicably" takes 332 ms. There is no performance optimization to be done inside remap_artist(). It already takes 0ms all the time, so something EXTERNAL to the script must be causing that blip. Foobar would also be unresponsive during that 1/3sec as well.

That's exactly what I'm seeing at startup as well.

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #184 –
Quote from: lender1257 on
Increasing the counter as snotlicker showed (I had no idea that smp enters something here) only leads to the fact that no more message is displayed, but the loading time remains the same. It takes far too long. I didn't have that with jscript-panel with the same number of tracks !! that means there must have been a change in the coding, or SMP reacts differently to the coding than jscript-panel.
You'd think I'd know the answer to this cause I very briefly "maintained" jscript_panel, but I don't.

@snotlicker do you know if jscript_panel executes scripts on the main UI thread or no? FSM does, and if that was a change from jscript it might account for the issues that lender and I are encountering.

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #185 –
In my machine (AMD APU A-10 with 57896 music files in a HDD the start up times are:

Code: [Select]
Spider Monkey Panel v1.4.1 (Library Tree: Library Tree v2.1.3 by WilB): initialized in 11642 ms
Spider Monkey Panel v1.4.1 (Biography: Biography v1.1.3 by WilB): initialized in 152 ms
Spider Monkey Panel v1.4.1 (Musicbrainz: Musicbrainz by marc2003): initialized in 147 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 69 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 38 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 43 ms
User Interface initialized in: 0:12.522745

Biography is not that bad, the slowest is Library Tree

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #186 –
not so different after all....

Removing library tree Biography takes the crown

Code: [Select]
Album List refreshed in: 0:15.254283
Spider Monkey Panel v1.4.1 (Biography: Biography v1.1.3 by WilB): initialized in 11029 ms
Spider Monkey Panel v1.4.1 (Musicbrainz: Musicbrainz by marc2003): initialized in 103 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 41 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 39 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 34 ms
User Interface initialized in: 0:26.975856

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #187 –
Quote from: paregistrase on
Biography is not that bad, the slowest is Library Tree
That's WilB's biography panel, not kgena_ua's. Library Tree is always slow, even outside startup for first load if you have a library of any significant size. It does a LOT of stuff, much of which can't be easily deferred.

Although your two posts demonstrate what I've been saying all along: In certain situations at startup the main foobar UI thread can be starved.

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #188 –
Quote from: MordredKLB on
Quote from: paregistrase on
Biography is not that bad, the slowest is Library Tree
That's WilB's biography panel, not kgena_ua's. Library Tree is always slow, even outside startup for first load if you have a library of any significant size. It does a LOT of stuff, much of which can't be easily deferred.

Although your two posts demonstrate what I've been saying all along: In certain situations at startup the main foobar UI thread can be starved.

I can not test the other bio, not works at all for me in linux ;).

I understand the library tree time, is logic that takes its time to start up: in fact is faster than album list.

But if the work of library tree and album list are equivalents and his start up are similar, why in the first case Biography only takes 152ms and in the second time takes 11029 ms?

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #189 –
Quote from: paregistrase on
Quote from: MordredKLB on
Quote from: paregistrase on
Biography is not that bad, the slowest is Library Tree
That's WilB's biography panel, not kgena_ua's. Library Tree is always slow, even outside startup for first load if you have a library of any significant size. It does a LOT of stuff, much of which can't be easily deferred.

Although your two posts demonstrate what I've been saying all along: In certain situations at startup the main foobar UI thread can be starved.

I can not test the other bio, not works at all for me in linux ;).

I understand the library tree time, is logic that takes its time to start up: in fact is faster than album list.

But if the work of library tree and album list are equivalents and his start up are similar, why in the first case Biography only takes 152ms and in the second time takes 11029 ms?

Just curiosity

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #190 –
Quote from: paregistrase on
But if the work of library tree and album list are equivalents and his start up are similar, why in the first case Biography only takes 152ms and in the second time takes 11029 ms?
FSM code runs in the main fb2k UI thread. For <reasons> the UI thread is getting starved and so execution happens VERY slowly.

I don't know what these <reasons> are, but they definitely seem to be caused by HDD activity in my case. Most likely the OS is preventing fb2k from reading the disk and so the thread is being blocked, but that's just a guess and could be different in different OS's and environments.

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #191 –
Quote from: MordredKLB on
Quote from: paregistrase on
But if the work of library tree and album list are equivalents and his start up are similar, why in the first case Biography only takes 152ms and in the second time takes 11029 ms?
FSM code runs in the main fb2k UI thread. For <reasons> the UI thread is getting starved and so execution happens VERY slowly.

I don't know what these <reasons> are, but they definitely seem to be caused by HDD activity in my case. Most likely the OS is preventing fb2k from reading the disk and so the thread is being blocked, but that's just a guess and could be different in different OS's and environments.

With wine in linux the UI is only drawn before the HDD activity ends in start up.

So if the panel try to start up his full execution is delayed until the ui fully load.

So the mayority of this start up time is waiting for ui start.

I understand it right?

Please be patience, I'm curious but not a programer  :P

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #192 –
I owe an apology to kgena_ua.

His version of Bio for spider Monkey Panel WORKS in wine.

I'm sorry I didn't saw it and only was tried the old version.

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #193 –
Quote from: paregistrase on
So if the panel try to start up his full execution is delayed until the ui fully load.
So the mayority of this start up time is waiting for ui start.
No and yes :D
For the UI to start a bunch of things have to finish first. One of those things is that FSM must finish its initial load: loading its own DLLs and code, then processing the script file and running any code it is told to run. However other things can cause that to take a long time.

Here's a dumb non-programming explanation that might make this whole discussion a little clearer:

Let's say you want to play a game of cards, but to start all the cards need to be in the correct Ace-to-King order by suit. Let's say at 12:00pm you drop all the cards on the table in a random pile and start sorting them. Your method is just to hunt for the very first card you want out of all 52 and then go on from there. In perfect conditions this process should take about 5 minutes. However while you're sorting your kid interrupts you asking you to fix him lunch, or pour him some water, or take him to the bathroom. Maybe the dog needs to be let out too. You also get a couple phone calls. Everyone of those things divides your attention or takes you away from the table where you can sort the cards. You finally finish at 12:30pm and can start your game.

Looking just at the clock it took you 30 minutes to sort your cards (initially execute the script) but during that time you were really only sorting cards for 5 or 6 minutes, and the rest of the time you were blocked from doing the task (waiting on the HDD or other things).

Now, you can come up with a better algorithm for sorting cards using multiple piles for each suit that maybe only takes 2 minutes, but if you keep getting interrupted it still might take you 25 minutes before you can start your game. Certainly better, but still the algorithm you use to sort the cards isn't the primary problem. This is the fundamental disagreement that @regor and I are having :)

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #194 –
Quote from: MordredKLB on
Quote from: paregistrase on
So if the panel try to start up his full execution is delayed until the ui fully load.
So the mayority of this start up time is waiting for ui start.
No and yes :D
For the UI to start a bunch of things have to finish first. One of those things is that FSM must finish its initial load: loading its own DLLs and code, then processing the script file and running any code it is told to run. However other things can cause that to take a long time.

Here's a dumb non-programming explanation that might make this whole discussion a little clearer:

Let's say you want to play a game of cards, but to start all the cards need to be in the correct Ace-to-King order by suit. Let's say at 12:00pm you drop all the cards on the table in a random pile and start sorting them. Your method is just to hunt for the very first card you want out of all 52 and then go on from there. In perfect conditions this process should take about 5 minutes. However while you're sorting your kid interrupts you asking you to fix him lunch, or pour him some water, or take him to the bathroom. Maybe the dog needs to be let out too. You also get a couple phone calls. Everyone of those things divides your attention or takes you away from the table where you can sort the cards. You finally finish at 12:30pm and can start your game.

Looking just at the clock it took you 30 minutes to sort your cards (initially execute the script) but during that time you were really only sorting cards for 5 or 6 minutes, and the rest of the time you were blocked from doing the task (waiting on the HDD or other things).

Now, you can come up with a better algorithm for sorting cards using multiple piles for each suit that maybe only takes 2 minutes, but if you keep getting interrupted it still might take you 25 minutes before you can start your game. Certainly better, but still the algorithm you use to sort the cards isn't the primary problem. This is the fundamental disagreement that @regor and I are having :)

The "for dummys" answer is more clear than the link  8)

so you can't do nothing about "the kid being a kid" (the delay of the ui) but even that is true a better way for "sorting" cards will make things better.

If is possible to delay the initiation of the script until the load of the ui there will be a gain in time, or even better, doesn't start the script until is really call by a user action.

or not?

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #195 –
Basically, you want all your expensive UI related scripts and such to be deferred until at least this:

Not sure about SMP or jscript panel, but with core SDK: initquit service, the on_init() function is called for various components after most of the player is started up. Of course, then you're racing with every single component that also has an initquit service.

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #196 –
I make some test with differents scripts.

First I put away Library Tree, Album list panel and both bios

Code: [Select]
Spider Monkey Panel v1.4.1 (Musicbrainz: Musicbrainz by marc2003): initialized in 610 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 49 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 40 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 45 ms
User Interface initialized in: 0:01.181741
FFmpeg version: 4.3.1
Loading
foo_enhanced_playcount: loaded
Querying last.fm: http://ws.audioscrobbler.com/2.0/xxxxxxxxxxx
Startup time : 0:04.657253

Then I put a Biography v1.1.3 by WilB

Code: [Select]
Spider Monkey Panel v1.4.1 (Biography: Biography v1.1.3 by WilB): initialized in 602 ms
Spider Monkey Panel v1.4.1 (Musicbrainz: Musicbrainz by marc2003): initialized in 119 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 47 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 44 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 41 ms
User Interface initialized in: 0:01.419245
Loading
FFmpeg version: 4.3.1
foo_enhanced_playcount: loaded
Querying last.fm: http://ws.audioscrobbler.com/2.0/xxxxxxxxxxxx
Startup time : 0:05.152534

Changing the WilB's bio to Biography, Covers, Albums, Title, Similar artist, Lyrics info.www.last.fm v14042021 by kgena_ua

Code: [Select]
Spider Monkey Panel v1.4.1 (Biography: Biography, Covers, Albums, Title, Similar artist, Lyrics info.www.last.fm v14042021 by kgena_ua): initialized in 11790 ms
Spider Monkey Panel v1.4.1 (Musicbrainz: Musicbrainz by marc2003): initialized in 127 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 41 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 36 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 39 ms
User Interface initialized in: 0:12.463360
Loading
FFmpeg version: 4.3.1
foo_enhanced_playcount: loaded
Querying last.fm: http://ws.audioscrobbler.com/2.0/xxxxxxxxxx
Startup time : 0:15.990977

The difference with kgna_ua is appreciable.

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #197 –
And when I import my layout before the last test (during runtime, not for start up) the time of script was:

Code: [Select]
Spider Monkey Panel v1.4.1 (Library Tree: Library Tree v2.1.3 by WilB): initialized in 78 ms
Spider Monkey Panel v1.4.1 (Biography: Biography v1.1.3 by WilB): initialized in 128 ms
Spider Monkey Panel v1.4.1 (Musicbrainz: Musicbrainz by marc2003): initialized in 46 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 38 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 35 ms
Spider Monkey Panel v1.4.1 (Last.fm Similar Artists + User Charts + Recent Tracks: Last.fm Similar Artists + User Charts + Recent Tracks by marc2003): initialized in 36 ms
Autobackup: Backed up 80 items to autobackup.20210514-032829.zip

So seems that if the scripts will load before the program get ready the impact will be less

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #198 –
Quote from: kode54 on
Basically, you want all your expensive UI related scripts and such to be deferred until at least this:

Make sense.

Important things first then the rest

Re: Biography Text, Album Info, Picture. www.last.fm

Reply #199 –
Quote from: kode54 on
Basically, you want all your expensive UI related scripts and such to be deferred until at least this:

Not sure about SMP or jscript panel, but with core SDK: initquit service, the on_init() function is called for various components after most of the player is started up. Of course, then you're racing with every single component that also has an initquit service.
Dude. I think you fixed it @kode54. Early returns are very promising. Gimme a bit to do some more testing though.

Code: [Select]
Spider Monkey Panel v1.4.2-dev+ce39bb09 (Georgia: Biography, Covers, Albums, Title, Similar artist, Lyrics info.www.last.fm v01052021 by kgena_ua): initialized in 578 ms
User Interface initialized in: 0:02.061759