Trade-off triggering events or calling a function directly from another module

Solar2D Lua Language
#1

I was wondering about this for a while now and don’t know the answer and how to look for one. Consider following chunks of code:

file1.lua:

local M = {} local doSth = function( ... ) ... end M.doSth = doSth Runtime:addEventLinstener("doThatThing", doSth) return M

file2.lua (version 1):

local M = require("file1") M.doSth( ... )

file2.lua  (version 2):

Runtime:dispatchEvent( { name = "doThatThing" , ...} )

The question:

Which option for file2 is prefered and faster? Is there any explanation on this topic anywhere?

#2

both of these solutions are valid, which one to use depends on how you want to structure the code in your app.
 
as to which is faster, i would say version 1 by a very very slight margin (assuming file2 is already loaded, etc). this is because doing event dispatch has a slight overhead compared to the straight call to doSth() in file2. however, i wouldn’t worry about it too much because Corona is fast. the *real* time consideration will be what your app DOES in doSth().  :slight_smile:
 
cheers, dmc 
 
aside: file1 can also be structured like so:

local M = {} function M.doSth( ... ) ... end Runtime:addEventListener("doThatThing", doSth) return M
#3

everything @dmccuskey said, adding…

the main practical advantage (imo) of the second form (events) is if your code doesn’t necessarily “know” (or you don’t bother to track) which object (assuming several or many possible) might potentially be listening for that event at any given moment.  so just dispatch the event, and whoever IS currently listening (if anyone) will get it.  otoh, if it’s always the same object listening with the same method, then no real advantage - you KNOW the target, so might as well just call THAT method of THAT object directly.  fwiw

#4

Many thanks for both answers!

#5

both of these solutions are valid, which one to use depends on how you want to structure the code in your app.
 
as to which is faster, i would say version 1 by a very very slight margin (assuming file2 is already loaded, etc). this is because doing event dispatch has a slight overhead compared to the straight call to doSth() in file2. however, i wouldn’t worry about it too much because Corona is fast. the *real* time consideration will be what your app DOES in doSth().  :slight_smile:
 
cheers, dmc 
 
aside: file1 can also be structured like so:

local M = {} function M.doSth( ... ) ... end Runtime:addEventListener("doThatThing", doSth) return M
#6

everything @dmccuskey said, adding…

the main practical advantage (imo) of the second form (events) is if your code doesn’t necessarily “know” (or you don’t bother to track) which object (assuming several or many possible) might potentially be listening for that event at any given moment.  so just dispatch the event, and whoever IS currently listening (if anyone) will get it.  otoh, if it’s always the same object listening with the same method, then no real advantage - you KNOW the target, so might as well just call THAT method of THAT object directly.  fwiw

#7

Many thanks for both answers!