Skip to content
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

Performance of MIMEType #120

Closed
Uzlopak opened this issue Sep 27, 2023 · 0 comments
Closed

Performance of MIMEType #120

Uzlopak opened this issue Sep 27, 2023 · 0 comments

Comments

@Uzlopak
Copy link
Contributor

Uzlopak commented Sep 27, 2023

I think that MIMEType can be improved significantly.

I created rn a PR regarding lazily parsing the MimeParams.

nodejs/node#49889

Also i could improve toASCIILower with this snippet:

const ASCII_LOOKUP = new Array(127).fill(0).map((v, i) => {
  if (i >= 65 && i <= 90) {
    return StringFromCharCode(i + 32);
  }
  return '';
})

function toASCIILower(str) {
  let result = '';
  for (let i = 0; i < str.length; ++i) {
    const code = StringPrototypeCharCodeAt(str, i);

    if (code > 90 || code < 65) {
      result += str[i];
    } else {
      result += ASCII_LOOKUP[code];
    }
  }
  return result;
}

Also why do we use SafeStringPrototypeSearch in encode? Cant we just use RegexPrototypeExec? Cant we manually inline the encode function into toString?

Is there a faster way to iterate the SafeMap? Why do we use a SafeMap and not a NullObject (because of the generator functions?

Can we avoid the generator fns? Does it make sense to avoid the generator fns?

Can we optimize parseTypeAndSubtype? Maybe also lazily parse the values? We need to throw errors in special cases, but other than that, we just have to store the string.

Why do we call in MIMEType toString FunctionPrototypeCall(MIMEParamsStringify, this.#parameters); and not
this.#parameters.toString()?

Questions over questions...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant