bucharest-gold / entente

A place for open discussion of Node.js middleware at Red Hat, including ideas for projects, collaboration, etc.
Apache License 2.0
5 stars 4 forks source link

Draft Fidelity performance update/review options/issues #85

Closed balunasj closed 8 years ago

balunasj commented 8 years ago

As discussed in the team meeting, Helio should describe the concerns, and create specific issues inside of the Fidelity project outlining what could/should be done.

Any questions, or items that need discussion could be discussed here or on the mailing list.

helio-frota commented 8 years ago

@lance today I did another attempt:

class Operations {
  resolvePromise (p, x) {
  process (p) {
  transition (p, state, value) {
}

Then call it with new on Fidelity class.

new PromiseModule()
Average (mean) 2723.936431784108
new Fidelity Promise
Average (mean) 2117.4053973013497

more slower due new.

Then make things static to avoid new:

class Operations {
  static resolvePromise (p, x) {
  static process (p) {
  static transition (p, state, value) {
}

Still slower but better than new version, and more slower then current code.

new PromiseModule()
Average (mean) 2534.9088455772117
new Fidelity Promise
Average (mean) 2118.432083958021

I Watched this presentation today to try to find more techniques and I saw functions vs methods, so I decided to give a try. Another interesting thing on the presentation is about 'code that probably will not be executed' at this time of video. So, Looking for coveralls, 98%+ of the fidelity code is executed. But currently I have no idea how to see if fidelity's benchmark code has some part of code that is not executed.

helio-frota commented 8 years ago

lanceball > helio-frota: but what I am saying is you don't need to create class Operations - just move those functions into the body of class FidelityPromise as static functions

helio-frota commented 8 years ago

Ok ! I'll try this, thanks!

helio-frota commented 8 years ago

Makes a lot of sense in theory but in practice we get the contrary: :/

Winner: new PromiseModule()
Compared with next highest (new Fidelity Promise), it's:
24.07% faster
Winner: new PromiseModule()
Compared with next highest (new Fidelity Promise), it's:
19.37% faster
Winner: new PromiseModule()
Compared with next highest (new Fidelity Promise), it's:
17.18% faster

hf@archT440 ~/p/fidelity ±master⚡ » node --version v6.9.1

lance commented 8 years ago

@helio-frota so at this point, I'm not sure there is much else to do here, unless you have some other thoughts on performance optimizations. Should this be closed?

Edit If there are any findings here that you think deserve their own issues in bucharest-gold/fidelity, please open them there.

helio-frota commented 8 years ago

@lance yes.