Something strange (Slow resolve on pageload) about yaku HOT 23 CLOSED

Thank you for your fast feedback! And that even in christmas time! 🍻

setimmediate speeded it up greatly, but its interestingly still slower than bluebird.

Here is the testing-environment 👩‍💻
bug.zip

Okay I tried it with an other nexttick library (https://github.com/medikoo/next-tick). This library had a better performance than setImmediate and the yaku logs showed up in the correct order (yaku before bluebird)

import bluebird from 'bluebird'
import Yaku from 'yaku'

//import setImmediate from 'setimmediate'
//
import nextTick from 'next-tick'
Yaku.nextTick = fn => nextTick(fn);

console.log(Yaku)

Yaku.resolve().then(function() {
  console.log('yaku1')
})

Yaku.resolve().then(function() {
  console.log('yaku2')
})

bluebird.resolve().then(function() {
  console.log('bluebird')
})

I think it would be very important to atleast show the nextTick info in the README at a more noticable position! What were your reasons to not include a nextTick in yaku? Size? Trust? :) next-tick is 1.86 KB-ish unminified :D

from yaku.

Good news! I found the problem, it was in my build process, complicated to give you a short description, but basically next-tick was packaged by webpack in a way like this:

function(process, setImmediate....) {
   ...nextTick...
}.call(shim, shim, shim, holy moly

Therefore nextTick just used webpacks setImmediate shim, which currently seems to be slow:
webpack/webpack#947

This only happend on the parts of the application, which were built by webpack. Yaku/nextTick, directly imported in rollup didn't had the problem.

I will probably remove all of the webpack stuff from my build process and just go to rollup ;)

Behind the scenes: I use yaku in a state management library Alo, and that is currently built by webpack. And this issue #41 first occured only when I worked on a example for alo (separate repository), which was built using brunch. Thus it was very tricky to find the real root reason for the slow pageload :(.

Thx for your help 🍰 !

If its okay for you, I will give you a closing-comment when I migrated/fixed the build process, and did a last test.

from yaku.

Great work! And it did remind me the weird behavior of webpack.

You can use this http://webpack.github.io/docs/configuration.html#node to disable webpack's process shim, it's enabled by default. In my experience, most times it only causes confusing.

from yaku.

By the way, Yaku had fast nextTick one year before, checkout the old version:

I removed it a year ago to keep myself focused, but now I may revert it back.

from yaku.

Thanks for the idea with the webpack configuration, i finally switched to rollup though :).

Now it works like a charm, and my lib is at 67 kb thanks to your lite approach 💃

from yaku.

Thanks for your feedback, I will take some time to find out what's going on there.

from yaku.

First, I suggest you to use this and try again: https://github.com/ysmood/yaku#yakunexttick
Maybe the problem is because Yaku use setTimeout by default, and it's slow.

var Promise = require('yaku');
require('setimmediate')
Promise.nextTick = fn => window.setImmediate(fn);

from yaku.

By the way, can I have you package.json and app/main.js, I need to reproduce your issue.

from yaku.

• There too many options, I don't know which one is the best.
• Yaku should be dependency free.
• When the setTimeout is slow, it means the UI is slowed down by intense CPU workload, such as the first page rendering. For your case, even though bluebird is faster, there no actual meaning to be fast when the UI is slow, the bottlenect is on the UI rendering workload not on the Promise lib. The overhead of setTimeout on the client side is insignificant.

from yaku.

If next-tick is good enought, and currently we are sure it's the best in the industry, I think I will make it the default option. For now, I'll just update the documentation, because it's a little better than setimmediate (next-tick is not that good for old IEs)

from yaku.

Do however you like its your library! ;), (https://npms.io/search?q=nextTick) the score of next-tick is not too bad though!

When the setTimeout is slow, it means the UI is slowed down by intense CPU workload, such as the first page rendering. For your case, even though bluebird is faster, there no actual meaning to be fast when the UI is slow, the bottlenect is on the UI rendering workload

What do you mean with UI rendering? Rendering of html? Or just the UI of the browser?

from yaku.

Wait :/, i noticed something... -.-, as soon as a remove the line import bluebird from 'bluebird' the slow loading time shows up again 💩

I think bluebird polyfills something which then is used by the nextTick polyfill xDDD, will look into it and give you feedback later ;)

from yaku.

I tried to find something in bluebird, which looks like a nextTick or a polyfill and could only find this info:

https://github.com/petkaantonov/bluebird/wiki/Error:-No-async-scheduler-available

I've spent now many hours to solve this issue and couldnt find a solution without bluebird :]... So i decided to just use bluebird core as a temporary workaround :/.

from yaku.

That will be a bad sign if so, because it means bluebird silently mutates some global function. But I think it's not what really happens.

So again please show me your project details, such as the "package.json" and "main.js"

from yaku.

I already did 17 hours ago

Here is the testing-environment 👩‍💻
bug.zip

(https://github.com/ysmood/yaku/files/672920/bug.zip)

from yaku.

Oh, so sorry for my blindness.

from yaku.

No problem, oh and you can run it (after install) with rollup -c .rolluprc

from yaku.

Bluebird

import Bluebird from 'bluebird'
console.time('bluebird')

Bluebird.resolve().then(function() {
  console.timeEnd('bluebird')
})

Bluebird.resolve().then(function() {
  console.timeEnd('bluebird')
})

Result:

bluebird: 1.451ms
bluebird: 4.895ms

Yaku

import Yaku from 'yaku'

import nextTick from 'next-tick'
Yaku.nextTick = nextTick

console.time('yaku')

Yaku.resolve().then(function() {
  console.timeEnd('yaku')
})

Yaku.resolve().then(function() {
  console.timeEnd('yaku')
})

Result:

yaku: 1.301ms
yaku: 3.738ms

Everything seems well, I cannot reproduce your issue.

from yaku.

Was the bluebird test in the same file as the yaku test?

from yaku.

Sure, no. These are two separate entry files.

from yaku.

To make sure everything is clean, I use browser's incognito mode without any browser extension.

from yaku.

Maybe your rebuild process isn't correct. This is the bundled file, you can check the source code, no bluebird insdie:

bundle.js.zip

from yaku.

Kk, i tried it a moment ago on a different machine and got similar results like you. Will do some last checks on the original machine this evening. Maybe its really something wrong in the rebuild process, some cache or whatever ^^.

from yaku.