You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Applications using a common EmbedIO WebServer setup display a high CPU usage, even when idle.
I've tested this behavior both in my Nexus 5 (hammerhead) device and also on my Linux laptop. While it keeps the cpu spinning at a 4~5% on my laptop, the issue blows up to 25% when running on the smartphone. This is a huge issue, since it drains the battery really fast.
This issue might be related to this one there in the EmbedIO repo.
To Reproduce
Just running the EmbedIO.Samples project normally is enough to witness the issue.
Expected behavior
The expectation would be the server to consume close to 0% of CPU when idle, since it seems to be using async sockets.
Desktop (please complete the following information):
OS: Manjaro Linux 23
Smartphone (please complete the following information):
Device: Nexus 5 (hammerhead)
OS: LineageOS 20
Additional context
I did some poking around the lib and was able to figure out the likely issue: The Terminal, in the Swan.Lite project, class has some concurrency structures that are getting called back/timeout too frequently. I did some profiling for about 6s~10s on the idle app and the number of calls were huge:
The above keeps my smartphone busy/awake enough to impact negatively in the battery lifetime.
The Terminal class, along with a few more in Swan.Lite, are making use of static constructors to initialize themselves which makes the issue almost impossible to work around from outside the embedio/swan projects, since every single call that you´d make to clear the list of loggers or something similar trigger those static constructors.
EmbedIO is a really nice project and I want to keep using it for my smartphone project. Also, while I would like too see it decoupled from Swan, I'm aware the level of effort would not be small.
Describe the bug
Applications using a common EmbedIO WebServer setup display a high CPU usage, even when idle.
I've tested this behavior both in my Nexus 5 (hammerhead) device and also on my Linux laptop. While it keeps the cpu spinning at a 4~5% on my laptop, the issue blows up to 25% when running on the smartphone. This is a huge issue, since it drains the battery really fast.
This issue might be related to this one there in the EmbedIO repo.
To Reproduce
Just running the
EmbedIO.Samples
project normally is enough to witness the issue.Expected behavior
The expectation would be the server to consume close to 0% of CPU when idle, since it seems to be using async sockets.
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
I did some poking around the lib and was able to figure out the likely issue: The
Terminal
, in theSwan.Lite
project, class has some concurrency structures that are getting called back/timeout too frequently. I did some profiling for about 6s~10s on the idle app and the number of calls were huge:The above keeps my smartphone busy/awake enough to impact negatively in the battery lifetime.
The
Terminal
class, along with a few more inSwan.Lite
, are making use of static constructors to initialize themselves which makes the issue almost impossible to work around from outside the embedio/swan projects, since every single call that you´d make to clear the list of loggers or something similar trigger those static constructors.EmbedIO is a really nice project and I want to keep using it for my smartphone project. Also, while I would like too see it decoupled from Swan, I'm aware the level of effort would not be small.
I've put together a quick workaround, in the form of a suppression flag, that worked really well for me:
V3.X...arno-cassaniga:swan:fix-terminal
The patched EmbedIO sample looks like this:
unosquare/embedio@v3.X...arno-cassaniga:embedio:swan-manual-init
I'd like to know if you guys could come up with something similar/better to address this issue here in the main repo.
Ofc, I'll be happy turning my changes into a PR here as well, if desired.
All the best.
The text was updated successfully, but these errors were encountered: