Search code examples
javascriptelectronipcevent-listener

Which one is better way in terms of performance to use IPC listener in electron?


I have a lot of IPC listeners (more than 30) on my electron application, but I wonder which one is better in terms of performance.

The first solution (Implement IPC listener as many as it needed):

ipcMain.on('appLanguageChange', (event, data) => {
    //do something with data
})
ipcMain.on('current-patient-ask', (event, data) => {
    //do something with data
})

ipcMain.on('patient-set', (event, data) => {
    //do something with data
})

//Still need many listeners below..


The second solution (Using Switch and only implementing one IPC listener):


    ipcMain.on('data-flow', (event, topic, data) => {
        switch (topic) {
            case "appLanguageChange":
                //do something with data

            case "current-patient-ask":
                //do something with data

            case "patient-set":
                //do something with data
                break;
             //Still need many cases below..
    })

Currently, I am using the second solution, is it a good approach? Because I am aware that some people could get a warning that too many IPC listeners have already implemented. How many maximum IPC listeners could be implemented if there is a limitation? It would be better if someone could explain the pros and cons of the two methods. Thanks in advance.


Solution

  • As Electron uses Node.js underneath and Electron's IPC is based on Node events, any limits would be imposed by Node and not Electron (unless otherwise defined by electron, which I don't believe it is).

    As per the latest Node.js Event documentation, once you have more than 10 listeners per event a warning will be emitted. The thing to note here is "more than 10 listeners per event".

    See this Node link for more information: events.defaultMaxListeners

    As each ipcMain.on('channelName', () => { ... }) is a listener for, in this example, an event named channelName, you would need more than quantity 10 of the ipcMain.on('eventName', () => { ... }) methods in your code before a warning is throw.

    As all your ipcMain methods seem to be for different event names, there is no operational benefit between either of your solutions.

    That said, your first solution would be the preferred solution, allowing you to place your individual ipcMain calls into their "associated files". EG: appLangaugeChange events would be coded within your language scripts whilst your any patient events would be coded within your patient scripts. This will keep your code seperated, logical, expandable and simple to debug.

    Additionally, as your project grows, a particular section of code can listen for an event emitted by an unrelated section of code, if needed. EG: Submitting some new information on a form may update more than one panel in your main window, or update multiple child-windows, all at the same time.

    On the discussion of "performance", if your events were firing every couple of milliseconds then one would want to look at micro-optimisation. But based on the event names, this is not the case, so any solution would work. If anything, it would probably be more based on your preferred coding style.

    As a closing note, consider the ipcMain method and its associated Electron methods only as an extension of Node events. They are not special or magical, but only a simple observer design pattern. This way, you will write better, more modular code.