search

lukeed / obj-str

A tiny (96B) library for serializing Object values to Strings.
MIT License
249 stars 7 forks source link

babel: can we avoid the leading space? #7

Closed minushabens closed 3 years ago

minushabens commented 3 years ago

Referring to this: https://github.com/lukeed/obj-str/tree/master/babel-plugin-optimize-obj-str#leading-space:

is there any way to delete that space?

Can we avoid that space at all? I mean, we have all the time at compile time, nope?

lukeed commented 3 years ago

Hi there,

It you look at the implementation PR (#6) you'll see that it originally was an option. However, as you can see in that discussion, the output this plugin produced to avoid a leading space was far more verbose & expensive to run.

This plugin can only make the optimizations you're thinking of if everything is known/static at compile time, which isn't likely -- and if it is, then you didn't need to be using obj-str in that instance.

Because of this, we removed the option to avoid the possibility of giving you a transform bigger than obj-str itself... that'd be silly.

Hope that helps!

minushabens commented 3 years ago

the output this plugin produced to avoid a leading space was far more verbose & expensive to run

I used this to calculate your examples.

As you can see the results are also excellent in the case of many replacements.

And about this comment:

maybe should mention the inflection point where this plug-in is no longer worth it. In this sample, another 2-3 replacements of similar complexity completely outweighs just using obj-str directly. (I know leadingSpace:true buys a bigger headstart)

What do you mean with completely outweighs? Size? Speed?

For the size side, maybe as @alanorozco said terser and similar can help us.

For the speed I think that in both cases (leading space or not) it is a winning solution for both a few classes and many (as that bench shows).

We would like to use it extensively in small components (Vue, React, Preact) rendered many times even hundreds all together and we're trying to understand how to best measure.

What do you think?

lukeed commented 3 years ago

What do you mean with completely outweighs? Size? Speed?

Size. It relates to the first point too. After a few replacements, the new code is the same size (or larger) than obj-str's original size. All replacements are inline & cannot share runtime code, which means this is linear growth. Terser doesn't help here either for the same reasoning -- all it can do is lower the size-cost of each replacement so that it takes more of them to hit that "inflection point". The output was already very small, so at best, this would allow "2-3" to be "3-5"

If you're looking for speed, use the current transform. A leading space is not worth the (slight) perf loss and added runtime code. That's why it was removed.

alanorozco commented 3 years ago

For the size side, maybe as @alanorozco said terser and similar can help us.

To clarify, the previous point about terser was related to constant expressions, not leading spaces. (We ended up evaluating expressions like terser would.)

I agree with @lukeed regarding size of expressions with optional leading spaces.