-
Notifications
You must be signed in to change notification settings - Fork 285
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
Provide performant iconv.encodeInto API (previously iconv.byteLength) #308
Comments
It would require significant effort, as all the logic of all codecs would
have to be duplicated and adjusted.
What's your use case?
…On Mon, Feb 27, 2023, 05:24 Viktor Podzigun ***@***.***> wrote:
Currently one can use:
iconv.encode(str, encoding).length
but it's slow because it creates intermediate and immediately discarded
buffer.
Would be better to expose similar but efficient api:
iconv.byteLength(str, encoding)
—
Reply to this email directly, view it on GitHub
<#308>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEZKHNQSZBOFQ3PRRCWIA3WZR6G3ANCNFSM6AAAAAAVJGTPUQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I see, would it be then at least possible for now to provide additional method, similar to TextEncoder.encodeInto:
I have a use case, where I need to get byte lengths for bunch of strings in specific encoding. |
This one is easier but still a significant change. I'll look into supporting it in the next version. To help me prioritize and design it, could you provide more data about your use case? I.e. what's the average string length, is there anything special in the distribution of their lengths, the codec you're planning to use (at least single charcter vs double character), how many conversions per second do you have per node process? Maybe also high-level overview of what you're trying to do (if possible of course). This additional method would help in some use cases and not in others, so I just want to make sure it'll actually make a difference in your case. |
That would be great, thank you @ashtuchkin for your quick reply and support! I would need it for the file viewer that I'm developing as part of FAR.js app. To show file content in the Until now I was using Buffer encodings, but plan to switch to your nice But it's not urgent, I can use Thanks again! |
That makes sense, thank you for the context! |
Currently one can use:
but it's slow because it creates intermediate and immediately discarded buffer.
Would be better to expose similar but efficient api:
The text was updated successfully, but these errors were encountered: