-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
drop legacy browsers #41
Comments
Hm, I sorta feel like it's already plenty small? Bundlephobia says 430B min+gz. I'm not sure saving ~100 bytes (~0.1kB) is worth dropping legacy browser support... |
it's 40% less before gzip (so 40% less parsing) but I agree that this library is small anyways.. just thought we could further improve it.. would you be open to fix the memory leak? not sure about the browser support - is it just chrome? because Chrome 51 is now 7 years old |
40% of a small number is still small... 🙂 Sorry to be "that guy," but I was curious, so I wanted to put an absolute number on it. According to a WebPageTest run using an emulated Moto G4 phone, it takes about 8ms of compilation and 10ms of scripting to load this library. So saving 40% on parsing would save about 4ms (7.2ms if we can get 40% of the total). Probably this is due to script compilation no longer being a big bottleneck in Chrome. It's not really about the browser support; it's more about me needing to update this project, fix all the tests, migrate from Travis to Github Actions... it's an old project and a lot would need updating. Could you explain more about the memory leak? If the Worker is garbage collected, then the PromiseWorker should be garbage collected too. Browsers typically GC an object's listeners when the object is GC'ed, although I admit I haven't tested web workers so it could be a browser bug. |
oh I know that pain 😄 - no worries that's why I asked for your thoughts before sending a real pr
that's true - I guess there are more suitable cases for optimizations..
You are right - as soon as the worker is garbage collected the PromiseWorker will also be removed. here is a (untested) idea to prevent those memory leaks (expand)
let messageIds = 0;
const createPromiseWorker = (worker, userMessage) => {
let callback;
let messageId = messageIds++;
let onMessage = ({ message }) => {
if (!Array.isArray(message) || message.length < 2) {
// Ignore - this message is not for us.
return;
}
var [id, error, result] = message;
if (id !== messageId) {
// Ignore - user might have created multiple PromiseWorkers.
// This message is not for us.
return;
}
worker.removeEventListener("message", onMessage);
callback(error, result);
};
worker.addEventListener("message", onMessage);
return new Promise((resolve, reject) => {
callback = (error, result) =>
error ? reject(new Error(error.message)) : resolve(result);
// web worker
worker.postMessage([messageId, userMessage]);
});
};
class PromiseWorker {
constructor(worker) {
this._worker = worker;
}
postMessage(message) {
return createPromiseWorker(worker, message);
}
} |
hey :)
would it be possible to drop some legacy browsers and save around 40% bytes?
this minifies to 324b:
further more we could export
createPromiseWorker
in addition to the current class based apithis would reduce the code size when using PromiseWorkers:
const z = e(w);z("hello");
vs the class based api:
const z = new E(w);x.postMessage("hello");
The text was updated successfully, but these errors were encountered: