Closed cxxxr closed 4 months ago
A benchmark has been added. Comparing before and after refactoring, there was no effect from the inline declaration.
before
Evaluation took:
2.750 seconds of real time
2.741348 seconds of total run time (2.681467 user, 0.059881 system)
[ Real times consist of 0.154 seconds GC time, and 2.596 seconds non-GC time. ]
[ Run times consist of 0.152 seconds GC time, and 2.590 seconds non-GC time. ]
99.67% CPU
9 lambdas converted
6,019,819,039 processor cycles
5,917,078,928 bytes consed
after
Evaluation took:
2.775 seconds of real time
2.764296 seconds of total run time (2.702289 user, 0.062007 system)
[ Real times consist of 0.150 seconds GC time, and 2.625 seconds non-GC time. ]
[ Run times consist of 0.153 seconds GC time, and 2.612 seconds non-GC time. ]
99.60% CPU
9 lambdas converted
6,074,091,252 processor cycles
5,917,121,456 bytes consed
Do you have any actual problem with it? I'm curious.
Looking at examples of its use in jsonrpc, it is referenced from multiple threads, so it is necessary to make it thread-safe. This is a preliminary refactoring for that purpose.
Fine, as I don't have a chance to use this library anymore. I suppose it was not for anything about performance since event-emitter is quite slow and does not care about speed.
I removed the inline declaration and refactored the code. I couldn't think of any particular advantages to this inline declaration, but as a disadvantage of inline declarations, debugging information is lost and the code becomes less readable. I also think it is better to optimize the internal implementation rather than inlining the exported functions.