Performance: compromise-three.mjs causes "long" main-thread task (~45ms) during 'Evaluate module'

[1951FDG]

Hi, I'm analyzing my page performance, looking at the Chrome DevTools performance profile, the "Evaluate module" step for compromise.bundle.mjs is taking ~45 ms on my machine.

Here is a screenshot from the profiler showing the long task (I've selected the compromise.bundle.mjs module evaluation):

Context / How I'm using it

Environment: Browser (Chrome)

Bundle: compromise.bundle.mjs (the ES module compromise-three.mjs)

I understand that 45ms of JS evaluation is not terrible, but on a loading my page, it's the longest task.

However, I wanted to ask, is this 45ms evaluation time expected for the main bundle?

[spencermountain]

hey Derrick - good eye!
yeah- compromise conjugates something like 10 thousand verbs on init. This is to seed the lexicon, without downloading or bundling them all up-front. I suspect you've caught that in action.
This wont happen if you load compromise/one - that doesn't come with any verbs, and should be much faster at runtime.

We need more front-end devs like you! Not enough people are looking at this stuff, and it matters a ton.
cheers.

[1951FDG]

Hey there,

So I decided on a approach to load compromise/one for initial displaying of text, and then later load compromise/three dynamically (where I can do more advanced stuff such as PII scrubbing) before submitting a form

what confuses me, is the docs on https://github.com/spencermountain/compromise, https://github.com/spencermountain/compromise?tab=readme-ov-file#transform

.normalize({}) - clean-up the text in various ways

it makes it seem that normalize is available to compromise/one, but then I get TypeError: doc.normalize is not a function

but the sources confirms that it is only available to compromise/three
https://github.com/spencermountain/compromise/blob/master/scripts/typescript/one.ts
https://github.com/spencermountain/compromise/blob/master/scripts/typescript/three.ts

[spencermountain]

sorry Derrick, i haven't had a chance to look at this properly.
it may just be the types that are wrong - the normalize function is used for a bunch of internal stuff, so probably is defined in /one, though i can check to make sure.
will let you know
cheers

[spencermountain]

hey, you're right - I've moved the normalize section in the readme file to the appropriate place.
cheers