Slow EventGhost Performance

If you have a question or need help, this is the place to be.
Post Reply
The Eight-Bit Link
Posts: 3
Joined: Sun Sep 09, 2018 4:51 am

Slow EventGhost Performance

Post by The Eight-Bit Link » Sun Sep 09, 2018 5:00 am

Hi, I've got a Griffin PowerMate, and I wanted to use Eventghost instead of the software that comes with the powermate. When I spin the wheel, I see the events start to pop up, but they all sort of stack up and get into a big mess. Is there something I missed in getting EG to work faster?

User avatar
kgschlosser
Site Admin
Posts: 4424
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Slow EventGhost Performance

Post by kgschlosser » Sun Sep 09, 2018 8:20 am

you have to provide screen shots or a copy and paste of what is going on in the log.

I am not sure what you mean by a mess.
and what plugin are you using to get events from the Griffin PowerMate??

Now you use the term "stack up" I am guessing what you are referring to is the events that are generated get cached. What is happening with the "stacked up" deal is when an event comes in from a plugin that event gets run in a thread that we call the event thread. there is only the single event thread. if an event has come in that is running a macro. and another one comes in while this is taking place it gets put into a queue. and there it will be until the event that is running finishes up what it is doing. once it finishes the next event will be run. so if you have a knob style control wheel and you spin the thing extremely fast depending on how long it takes for the events that get triggered to finish processing the macros is going to cause the events to get queued. and even after you stop spinning the wheel events could continue to get triggered until it empties the queue.

Now you can forcibly empty the queue by running the clear pending events action. this will clear out the queue. maybe something you would add to the end of the macros that get run from the events that get generated.
If you like the work I have been doing then feel free to Image

The Eight-Bit Link
Posts: 3
Joined: Sun Sep 09, 2018 4:51 am

Re: Slow EventGhost Performance

Post by The Eight-Bit Link » Tue Sep 11, 2018 3:46 am

Okay, I understand. The only action inside the macro is a plus or minus 0.5% Master Volume, but this list of actions still took around ten seconds to execute. This is from a five degree turn of the wheel. If I disable the macros, EG is able to keep up with the event. I also use EG for an ATI All-in-Wonder remote and EG is able to keep up with quickly moving around on the mouse buttons, even with the mouse emulation macros on. Is there some way of making Change Master Volume execute faster, or is there something about the way EG works that means this won't go any faster?
Attachments
EventScreenshot.PNG

User avatar
kgschlosser
Site Admin
Posts: 4424
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Slow EventGhost Performance

Post by kgschlosser » Tue Sep 11, 2018 6:28 am

I know there was an issue with one of the releases and the changing of the volume. I do not remember if it is in the latest Release Candidate of EG. I would have to double check. is this is already done then it is going to be some other issue I will have to track down for ya.


if you edit the file

Code: Select all

c:\Program Files (x86)\EventGhost\eg\WinApi\SoundMixer.py
with a decent text editor. like Notepad++ or SublimeText and search the file for

Code: Select all

eg.Utils.time.sleep(0.5)
and change it to

Code: Select all

# eg.Utils.time.sleep(0.5)
if there is no # there already then this should fix your issue.

If there is a # already there I am going to need to now the name of the plugin you are using.

Have you tried using a different action other then setting the volume? You gave an example of using the ATI remote for moving the mouse and you said that works fine. try setting the actions you currently have setup to change the volume to moving the mouse instead. see if the same thing still happens. This is going to help me isolate if it is the plugin or if it is in EG.

i can write a quick script for ya if you right click on the change volume action and then click on "Copy as Python" then paste into a forum post. this will give me the exact action parameters that are being passed. with that I can write a loop that i can time to see how long it is taking EG to actually change the volume.


we need to try and narrow down where the cause can be.
If you like the work I have been doing then feel free to Image

User avatar
kgschlosser
Site Admin
Posts: 4424
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Slow EventGhost Performance

Post by kgschlosser » Tue Sep 11, 2018 6:50 am

EG is capable of processing thousands of events a second. it all depends on what actions are being run and also how the author of a plugin wrote the plugin.

There are 2 different events types that can be generated, one is what is called an enduring event while the other is a one time use event. what that means is if you have a remote and you press and hold a button down. if you only get a single event chances are the event that has been triggered is an enduring event. even tho you only see the single event that event is still running while you have the button pressed. it will only stop running once you release the button. the second type will produce events one right after the other in rapid succession if a remote button is held down. there are cases when the enduring event is used because the remote send in a pressed and then a released for the buttons. but if the button is held no data is sent. other remotes while holding the button down it will keep on sending in that the button has been pressed. I do not know how the control that you have functions. in respect to this.

Because of the single threaded nature of the processing of events in EG i personally do not like enduring events. this is because while a button is being held down on a remote no other events will be processed and will be placed into a queue. So if you wanted to use EG in a manner that i do where everything in my house is controlled by a single copy of eventghost having someone press the button on the remote to scroll up through 10000 movies would stop anything else form taking place in the house while that remote button is being held down. with the one time use events other events can take place and will get triggered in between the remote events.

I have a very experimental version of eventghost which overcomes this limitation by creating a new thread for each event that gets triggered. the only time an event would get queued is if an event gets triggered and while it is running an action the same event comes in. then it will get queued until the first one finishes. I am still trying to work out an easy to understand/use GUI interface for it. the 2 dimensional log is not something that a user would be able to understand what is going on if there was more then a single event running can you imagine having 20 events all being processed at the same time and putting data into the existing log?? OYE! what a mess that would be. This is the thing I have not been able to come up with a good solution for. It would have to be a custom drawn interface, and it would also have to be extremely fast. I started messing around with this a long while ago. I now have a much better understanding of python and my coding skills have improved and I do now know how to go about making it fast enough. I just have to come up with a design idea for the UI
If you like the work I have been doing then feel free to Image

Snowbird
Experienced User
Posts: 349
Joined: Fri Jul 03, 2009 10:04 am

Re: Slow EventGhost Performance

Post by Snowbird » Tue Sep 11, 2018 5:11 pm

Hi Kevin,
glad to see you're kinda back :)

It would be so nice if you are able to achieve what you described, running multiple events at the same time (and getting rid of EG stalling...). Regarding the log part, why don't you display the log pane horizontally instead of as it is now vertically ? One could have the whole events/macros/actions view at a glance, for example :

_____________________Log Pane_______________________________________

date/time----My.Event---------------My.Other.Event---------------One.More.Event---------------Any.Event.etc.----------------------------
date/time------Macro(My.Event)-----Macro(My.Other.Event)-------Macro(One.More.Event)------Macro(Any.Event.etc.)-----------------
date/time--------------------------------Action2------------------------------------------------------------Action4-------------------------------
date/time--------Action1-------------------------------------------------Action3------------------------------------------------------New.Event
.... so on

>> Horizontal Scrolling here in case we have dozens of Actions <<


____________________Configuration Pane________________________________
Computer
----Autostart
-----------Plugins

Just an idea, probably not the best, but you gotta start somewhere :)

User avatar
kgschlosser
Site Admin
Posts: 4424
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Slow EventGhost Performance

Post by kgschlosser » Tue Sep 11, 2018 7:47 pm

I posted a test version of it. let me see if i can locate it. and if i deleted the posts for it because of the issue we were having when we were hosted by godaddy, i will se if i can locate it on my computer.
If you like the work I have been doing then feel free to Image

The Eight-Bit Link
Posts: 3
Joined: Sun Sep 09, 2018 4:51 am

Re: Slow EventGhost Performance

Post by The Eight-Bit Link » Wed Sep 12, 2018 3:52 am

Right, so there's no what EG is doing is this

Code: Select all

eg.plugins.System.ChangeMasterVolumeBy(0.5, u'Primary Sound Driver')
When I change the macro to move the mouse, it runs perfectly, leading me to believe that it's how fast this runs
As for the UI, each event could be tagged with date, time, and thread, and maybe a filter to filter out each thread. That way it can just be left as-is almost.

User avatar
kgschlosser
Site Admin
Posts: 4424
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Slow EventGhost Performance

Post by kgschlosser » Wed Sep 12, 2018 6:43 am

The code below you will paste into a Python Script Action. then press the Apply button. then the Test button. in the log you should see volume change events. Set your master volume to 0 then click on the Test button. it is going to make 20 loops increasing the volume 0.5% each loop. so a total of 10%

When it is done it is going to print out how long it took. past that result into a post. Did you happen to check that file and see if that line was already commented out?.

Code: Select all

import time

start = time.time()
for _ in range(20):
    eg.plugins.System.ChangeMasterVolumeBy(0.5, u'Primary Sound Driver')
    
stop = time.time()
print 'total run time for a 10% change in volume:', (stop - start) * 1000, 'ms'


As far as the multi threaded event system. I wish it was that simple. because EG was originally designed to only deal with a single event/macro/action being run at any given time the containers that hold these objects we set up to only hold one. If i change that it is going to break pretty much all of the plugins as well any python scripts a user has. Now I have already hammered out that portion of it. The code is sloppy and I did it as a proof of concept. The changes I made keep the EventGhost API 100% in tact. there should be very minimal problems with it as far as plugin compatibility and the users scripts not needing to be changed. The issue I ran into is with the GUI core. EventGhosts core has a Main Thread, which is the first thread to be created when the process is made. There is an Action Thread which is the thread that actions get run in, the Event Thread this is what the events run in. and there is a message receiver thread for receiving windows notifications. The original design was very strange in how it was made. The original author must have had some kind of a plan when he designed it. But i do not know what this plan was. Because honestly the way it is currently designed actually makes it slower.


So this is what happens.

An Event gets created by a plugin. that event then gets added to a queue. that queue gets read by the Event Thread. the event thread grabs the event from the queue one at a time. it then iterates over every single macro in the tree to see if there is a matching event in the tree. if there is a matching event in the tree it then one at a time grabs the actions in the macro. it puts the action into a queue for the action thread to read. The the event thread sits there and wats for th action to finish getting run. one that is done the event thread moves on to the next.

It makes zero sense as to why the action is queue and the event thread simply goes on vacation until the action gets run. The action thread also gets used by GI elements which require the user to start them. and when the user click on add a macro. this gets pass over to the action thread to do. then the action thread then passes it over to the Main Thread. because the Main thread is the only thread that can change GUI elements. I do understand the purpose to use the action thread to get all the data together and then passes it to the main thread to create a specific element. doing this is what keeps the GUI from getting sluggish. what i do not understand is why does the event thread pass the actions to the action thread and then simply sit there. it should be doing the processing of the actions. There is a horrible amount of passing of data back and forth between threads. This is going to really slow things down.

EG is a single process/core application. even tho you can go and view how much CPU time EG is taking up per core what you are seeing is actually incorrect. a single process can only run on one core. in order to be able to run on multiple cores there would need to be multiple processes for a single application..

If you cause EG to run full tilt you will notice it will never use 100 % of any core. when it really is s=using 100 % of a single core. for the sake of making the numbers even say you have a 5 core computer. EG will never go above 20% CPU use. 20% of each core = 100% of a single core. Windows is showing you something that is not real. Spawning new processes in a dynamic fashion is usually not a wise thing to do in terms of performance. it is better to create the process and leave it running and pass information to it. This is what I need to do.

I need to make EG in a manner that would spawn a single process for each core. the main process would be reserved for handling the drawing of GUI elements. the other processes would be able to process any kind od data that we want. I could make a single process for events. and one for actions. But that is going to limit the speed in which things can be done. it is still having a single process handle all of the data. it is simply allowing us to add a slight bit of a performance gain. What needs to be done is all the processes (except for the GUI one) can handle actions/ events/organizing for a GUI element. this way we can pass data to a process that is not in high use at that time. I have been outlining how to do this for some time trying to come up with what would be the most efficient means of having EG run.

Because of Python 3.5+ having the ability to handle asynchronous data input and output this is the ideal mechanism for inter process communications. so now the hurdle is upgrading EG to use Python 3.5. this is a HUGE hurdle.
If you like the work I have been doing then feel free to Image

User avatar
kgschlosser
Site Admin
Posts: 4424
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Slow EventGhost Performance

Post by kgschlosser » Wed Sep 12, 2018 7:02 am

here is a link to the multi threaded event thing. I do not remember where i left off with it. and I haven't touched the code in about a year.

https://ci.appveyor.com/project/kdschlo ... /artifacts

be sure to backup your existing EG installation before installing this one.
If you like the work I have been doing then feel free to Image

Post Reply