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: Spider Monkey Panel (foo_spider_monkey_panel) (Read 341851 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #125
Uh, this 'Edit' menu problem drives me nuts )) I don't get it, why this happens (this only affects 'Edit' submenu, others work just fine):
Not sure what's going on here - it works fine for me (both with `Grab Focus` enabled and disabled).

1) this is getting called twice for some reason
2) Am I MisSinG SoMetHing wItH thE CasE herE?
Because reasons :D
Those are just typos.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #126
@davideleo your script looks like this for me
Spoiler (click to show/hide)
And there were no apparent memory leaks :\

I tested my script on a clean installation with no other plug-in, but spider monkey panel. The memory leak was more than apparent. How did you test it?
I really need to get to the bottom of this problem, because it is making spider monkey panel unusable for me.


P.S.
BTW, on a clean installation I realized that the reason for that appearance is that the script does not find the "MenuVisible" file (without extension) in the "settings" folder inside the foobar2000 configuration folder. It is normally created by another script.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #127
P.P.S.
I tested some of the sample scripts to see if I could find at least one with a similar behaviour. Eventually I found that the "track info + seekbar + buttons" by marc2003 increases memory usage by 0,8-9 MB at every button click without releasing it, but it looks like marc2003 managed the issue, because it is released when (and apparently only if) the total memory delta is around 20MB.

EDIT
I made a mistake: it's not the button click that increases memory, but the playback state change, triggered by the button click.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #128
I made some steps forward in my inquiry on the memory-greedy script.

First of all I realized that memory usage increases only when several repaint actions are executed sequentially at close intervals, therefore I managed to lessen its impact by limiting the repaint action to when it is actually required, rather than on any on_mouse_move event.

That didn't solve the issue, though, and if I move the mouse very quickly, over the panel, I can still reproduce it, even if it takes longer to reach dangerous levels.

Anyway, I finally tested the same script on a JScript panel, on the same clean installation of the Spider Monkey panel. Here's what happened (yes, I know I look like a weirdo). I moved the mouse up and down on the JScript panel for about one minute and - as you can see in the task manager - the memory level is stuck on 677,2 MB. There is only a slight increase towards the end, released right after. The same action on the Spider Monkey panel immediately starts raising the memory in use and after one minute it's well over 680 MB.

Sorry if I sound obsessed, but since I'm still learning javascript, it's very important for me to understand what I didn't get right, before I move on to more advanced scripting.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #129
but it looks like marc2003 managed the issue, because it is released when (and apparently only if) the total memory delta is around 20MB.
That's just GC kicking in - it has several triggers, one of which is the amount of allocated memory. I.e. you don't have to `Dispose` anything manually in 99.9% cases in SMP.

What about the GC settings in the advanced preferences? Should I  mess around with them?
You should not =)

when you write that there were no apparent memory leaks, do you mean that triggering the on_mouse_move() doesn't increase memory usage or that the memory increase is then released? BTW thanks a lot for taking a look.
The memory increase is minuscule and it's not permanent - it's  cleaned up properly after sometime with GC (i.e. it's not a leak).

[EDIT] Can you download the debug version of SMP and enable GC zeal and check if memory is still leaking for you?
Debug version: https://ci.appveyor.com/api/buildjobs/rylakh87w1kuotm2/artifacts/_result%2FWin32_Debug%2Ffoo_spider_monkey_panel.fb2k-component_debug
GC Zeal: Preferences > Advanced > Display > Spider Monkey Panel > GC > Zeal > Enable

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #130
@davideleo you can also try the latest Nightly build (which is available via link in OP) - I might have fixed the leak there.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #131
With the nightly build (1.1.6-beta+80ac164) the behavior is unchanged and when I try installing the debug version I get this message:
Quote
Failed to load DLL: foo_spider_monkey_panel.dll
Reason: This component is missing a required dependency, or was made for different version of foobar2000.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #132
With the nightly build (1.1.6-beta+80ac164) the behavior is unchanged...

I think it was not the latest version. Anyway I just tried  1.1.6-beta+f3d6584 and it behaves in the same way.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #133
With the nightly build (1.1.6-beta+80ac164) the behavior is unchanged
Are you sure? Note that GC does not kick in immediately, that is 10mb of allocated memory is not enough to trigger GC. Try reaching 100mb of allocations.

This component is missing a required dependency, or was made for different version of foobar2000
I will send you a PM with missing dlls later this evening or tomorrow.

 

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #134
Are you sure? Note that GC does not kick in immediately, that is 10mb of allocated memory is not enough to trigger GC. Try reaching 100mb of allocations.

You are right! I gave the job to a timer, set to execute the repaint action once every millisecond. Right after startup, foobar2000 was using 677MB. After about 7 minutes the GC kicked in and memory usage dropped from 825MB to 690MB. I didn't clear the timer the first time and watched it repeat the cycle with the exact same values.
Just to make sure I tested the release version, too, and to my surprise it performed even better, dropping from 820MB to 687MB.
That's quite encouraging, even though I don't really understand why a script like mine would use so much memory for what to me looks basically like reassigning already allocated variables.



I will send you a PM with missing dlls later this evening or tomorrow.

Thanks a lot, I really appreciate your attention.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #135
I don't really understand why a script like mine would use so much memory for what to me looks basically like reassigning already allocated variables

GC is tuned for the best performance with multiple active SMP panels and heavy-allocating scripts, so it might be not aggressive enough for simple (that is light-allocating) scripts. That said, your case helped me to discover a bug, which made GC to be more lenient with memory allocation than it should've been. You can check out the fix with the latest Nightly build =)

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #136
You can check out the fix with the latest Nightly build =)

I just tested the script with beta version 2fdc8be and it behaves similarly, perhaps slightly worst: GC kicked in at 835MB (higher threshold than beta f3d6584) and dropped to 694MB (higher residual than beta f3d6584).
The fact remains that with JScript panel the same script does not raise memory usage at all. I recorded one more video which shows the task manager while two identical foobar2000 installations run the same script, one with JScript panel and one with Spider Monkey panel. The timer is set on start-up, and the two installations are launched simultaneously. Mind that no dispose() method was added in the JScript panel version.



GC is tuned for the best performance with multiple active SMP panels and heavy-allocating scripts, so it might be not aggressive enough for simple (that is light-allocating) scripts.

I'm a bit puzzled now: is JScript panel better tuned for light-allocating scripts? Is it more advisable for simple ones like mine?
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #137
I just tested the script with beta version 2fdc8be and it behaves similarly
Hm... That's weird... I'm currently reworking GC a bit, so hopefully the memory usage will go down with next builds.

The fact remains that with JScript panel the same script does not raise memory usage at all.
Because JSP does not have GC at all, which has it advantages like never using more memory than currently needed, but at the cost of the performance. See the following post for a bit more info and performance trade-off example: https://hydrogenaud.io/index.php/topic,116669.msg963036.html#msg963036

I'm a bit puzzled now: is JScript panel better tuned for light-allocating scripts? Is it more advisable for simple ones like mine?
I've never said anything like that. SMP and JSP are different beasts with different memory allocation policies. SMP uses (generally) more memory than JSP, but provides enhanced performance and smoother UX instead.
What I did say, is that I tuned SMP GC policies for more heavy scripts. So, while it uses more memory with light scripts than it could've (i.e. it would accumulate more memory before purging it), it consumes CPU time drastically less with heavy scripts than it would've otherwise (which results in smoother UX and etc and etc).

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #138
I've never said anything like that. SMP and JSP are different beasts with different memory allocation policies. SMP uses (generally) more memory than JSP, but provides enhanced performance and smoother UX instead.
What I did say, is that I tuned SMP GC policies for more heavy scripts. So, while it uses more memory with light scripts than it could've (i.e. it would accumulate more memory before purging it), it costumes CPU time drastically less with heavy scripts than it would've otherwise (which results in smoother UX and etc and etc).

I see, that makes sense, thanks for the explanation. I couldn't quite relate it to what I's experiencing because other heavy-looking scripts by professional coders didn't increase memory usage as much and my fear was that I was ignoring some basic good practice in my scripts. Eventually I found at least one professional script with a much bigger impact on memory and that reassured me a bit.
I'm late


Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #140
I'm testing beta 6cc1cbd. The memory increases at a similar pace than the previous ones, but apparently GC comes round more often and with a smaller truck.
With foobar2000 starting up at 670-680 MB, beta 2fdc8be and the stable release both need at least 825-835 MB (but today it was 850-860 MB, just to make things more random!) before dropping to more or less 700 MB. Beta 6cc1cbd drops from 800-810 MB to 760 MB.
My two cents: by looking at the first cycle only, it would seem a lot better. I wonder, though, whether a higher garbage residual means that, on the long run, the average memory usage is bound to increase more rapidly. What is also hard to tell is how multiple panels, working together in a real usage set up, would actually perform: analytically speaking the single panel is better off with a lower peak, but a higher residual means that the overall uncollected garbage level is generally higher. So, except for the very rare case of all scripts approaching their memory cap at the same time, I can't tell really which one is more advisable.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #141
With foobar2000 starting up at 670-680 MB, beta 2fdc8be and the stable release both need at least 825-835 MB (but today it was 850-860 MB, just to make things more random!) before dropping to more or less 700 MB. Beta 6cc1cbd drops from 800-810 MB to 760 MB.
Mind though, that you should differentiate between total memory usage (i.e. via task manager) and SMP memory usage (via `window.TotalMemoryUsage`).

What is also hard to tell is how multiple panels, working together in a real usage set up, would actually perform: analytically speaking the single panel is better off with a lower peak, but a higher residual means that the overall uncollected garbage level is generally higher
Whatever the case it should not `leak` anymore. That is, SMP average memory usage should stay mostly the same.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #142
Whatever the case it should not `leak` anymore. That is, SMP average memory usage should stay mostly the same.

I monitored the memory values for over 2 hours (not literally, I recorded 2 hours of task manager and then scrolled the frames through) because I was curious of the GC behavior on the long run, so now I have a bigger picture. The new beta stabilizes already after the first GC action, whereas the previous beta and the stable release keep on raising the baseline - and to a lesser extent the peak level - for over one hour! That's a long time and if you don't know it will come to an end, it really looks like a bad memory leak. The comparison I made above did not take this into account: I compared the stabilized memory baseline of the new beta with the still growing baseline of the other two. Once the values are stable, the winner is the new beta by all means.


Mind though, that you should differentiate between total memory usage (i.e. via task manager) and SMP memory usage (via `window.TotalMemoryUsage`).
You shouldn't have told me. Now I know what I'll do in the next days.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #143
And now for something completely different: is it possible to read and edit the search pattern of an autoplaylist via JScript?
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #144
And now for something completely different: is it possible to read and edit the search pattern of an autoplaylist via JScript?

Yep :) plman.ShowAutoPlaylistUI(pl_idx);

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #145
Yep :) plman.ShowAutoPlaylistUI(pl_idx);

As far as I know that opens the autoplaylist properties dialog window. I want to read (and possibly edit) the query pattern by code.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #146
And now for something completely different: is it possible to read and edit the search pattern of an autoplaylist via JScript?
fb2k does not provide such API, so neither SMP nor JSP have this feature.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #147
I apologize for the lack of updates (and the promised fixes), so here is a bit info to those who care(^^):
Recently my motivation suffered a huge blow from Mozilla and it's shenanigans, which (coupled with my usual lack of free time) mostly stalled any progress on the next SMP release. Hopefully, the motivation will restore itself (at least partially) soon enough, but it may take some time...
Regardless, the current SMP version (and the nightly build as well) should be stable enough to last till the new release =)

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #148
No need to apologize: as far as I remember, hardly any component has had the support you've been providing so far.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #149
@TheQwertiest
Code: [Select]
huge blow from Mozilla and it's shenanigans

That's disappointing news & hopefully not too restrictive in the future. All your excellent hard work & effort is much appreciated on this marvellous plug-in.