performance of parser

[pke]

I profiled my normalization function that creates about 120 opening_hour objects and it takes a whopping 3 seconds. Is there a way to speed that up? Has the parser been optimized for performance yet?
I might move the creation of those objects to a worker so that the main app thread is not blocked.

[ypid]

Not much work has gone into performance optimizations yet.

[pke]

Ok, then I'll risk a deeper look with the profiler.

[ypid]

I read a part of the implementation and it looked rather inefficient. To make it short, #213 contains a patch which improves common constructor calls by factor 6. I expect more such inefficiencies. Note that I started with this project without any prior JavaScript knowledge and not so much programming experience back then. Also JavaScript is not really my main programming language (currently Python I would say).

Ok, then I'll risk a deeper look with the profiler.

Looking forward to your pull requests 😉

[pke]

Thanks for the efforts. Hadn't had time to check myself in a profiler yet. But lookup is always good.
Probably changing the regex to match "24/7" early on might also improve perf, depending on the scenario.

[ypid]

Probably changing the regex to match "24/7" early on might also improve perf

Should already be pretty early or do you see further room for improvement?

[pke]

I wonder why the parser includes this awful regex
https://github.com/opening-hours/opening_hours.js/blob/master/index.js#L593

Is it really part of the spec that the opening hours string can be localized?
If not, I'd opt to remove that and simplify the regex.

[pke]

re the "24/7". It's not the first one. Its inside the while loop after tmp = value.match(/^([a-z]{2,})\b((?:[.]| before| after)?)/i); even.
What circumstance would be a valid input value where "24/7" is only a part of and not the complete input? Like how likely is it that before and after "24/7" comes another valid token? Can there be a fallback token?

[ypid]

What circumstance would be a valid input value where "24/7" is only a part of and not the complete input?

It is illogical to do this but that does not keep people from doing just that (search for 24/7) and the spec disallow this. That is why the lib gives a warning in those cases.

Can there be a fallback token?

Mean a fallback rule? Sure, why not. This would even be allowed by the spec but it is illogical as well (which is why the lib gives a warning here as well).

Is it really part of the spec that the opening hours string can be localized?

No and never will be. This is part of the error tolerance. The reason it is in the core is historical. The lib cares for OSM first of all. Please refer to #143

[ypid]

@pke Just because you don’t use this lib anymore does not mean that you have to close valid issues you reported ;-) Reopening.

For reference, you probably switched to https://github.com/pke/simple-opening-hours. I guess such info is always interesting for others reading this.