Performance Monitoring flags two regex taking majority of cli time

[JasonKleban]

What version of Tailwind CSS are you using?

3.4.14

What build tool (or framework if it abstracts the build tool) are you using?

postcss-loader: 8.1, webpack 5.96

What version of Node.js are you using?

v21.1.0

What operating system are you using?

Mac, Windows

Describe your issue

In a fairly small project tailwind is taking 26 seconds. I profiled it with Chrome DevTools npx --node-options=--inspect-brk tailwindcss -i .\src\input.css and see that some specific regexes are taking up a majority of the time:

I don't think this is project-specific. I'm suspecting that these regexes should be re-evaluated for performance - but I have not been able to find where these regexes are in the source.

((?=(((?:([^\s"'`\[\\]+-)?\[[^\s`]+\]\/[\w_-]+:|([^\s"'`\[\\]+-)?\[[^\s`]+\]:|[^\s`\[\\]+:))+))\2)?!?(?:\[[^\s:'"`]+:[^\s\[\]]+\]|\[[^\s:'"`\]]+:[^\s]+?\[[^\s]+\][^\s]+?\]|(?:-?(?:\w+)|@(?:\w+))(?:(?:(?:-(?:\w+-)*\['[^\s]+'\]|-(?:\w+-)*\["[^\s]+"\]|-(?:\w+-)*\[`[^\s]+`\]|-(?:\w+-)*\[(?:[^\s\[\]]+\[[^\s\[\]]+\])*[^\s:\[\]]+\])(?![{([]])(?:\/[^\s'"`\\><$]*)?|(?:-(?:\w+-)*\['[^\s]+'\]|-(?:\w+-)*\["[^\s]+"\]|-(?:\w+-)*\[`[^\s]+`\]|-(?:\w+-)*\[(?:[^\s\[\]]+\[[^\s\[\]]+\])*[^\s\[\]]+\])(?![{([]])(?:\/[^\s'"`\\$]*)?|[-\/][^\s'"`\\$={><]*))?)

((?=(((?:@\[[^\s"'`]+\](\/[^\s"'`]+)?:|([^\s"'`\[\\]+-)?\[[^\s"'`]+\]\/[\w_-]+:|([^\s"'`\[\\]+-)?\[[^\s"'`]+\]:|[^\s"'`\[\\]+:))+))\2)?!?(?:\[[^\s:'"`]+:[^\s\[\]]+\]|\[[^\s:'"`\]]+:[^\s]+?\[[^\s]+\][^\s]+?\]|(?:-?(?:\w+)|@(?:\w+))(?:(?:(?:-(?:\w+-)*\['[^\s]+'\]|-(?:\w+-)*\["[^\s]+"\]|-(?:\w+-)*\[`[^\s]+`\]|-(?:\w+-)*\[(?:[^\s\[\]]+\[[^\s\[\]]+\])*[^\s:\[\]]+\])(?![{([]])(?:\/[^\s'"`\\><$]*)?|(?:-(?:\w+-)*\['[^\s]+'\]|-(?:\w+-)*\["[^\s]+"\]|-(?:\w+-)*\[`[^\s]+`\]|-(?:\w+-)*\[(?:[^\s\[\]]+\[[^\s\[\]]+\])*[^\s\[\]]+\])(?![{([]])(?:\/[^\s'"`\\$]*)?|[-\/][^\s'"`\\$={><]*))?)

[philipp-spiess]

@JasonKleban Hey! Do you have a repro setup for the issue here including the config that's causing the 26 seconds builds? That's definitely not expected and also not what we're seeing.

I also tried to look for and can't find out where this regex comes from 🤔 Mind sharing the perf recording so we can look into the trace?

Generally, we are very close to cutting a beta release of Tailwind CSS v4 which is going to make it much easier for us to debug issues like this and since performance was a huge priority for v4 from the start, it's probably going to behave differently here already, if you want to give that a try. 👀

[JasonKleban]

Looks to be generated at runtime in lib\defaultExtractor.js:

let patterns = Array.from(buildRegExps(context));

and so this is the lib/regex.js concatenating the subpatterns for function* buildRegExps()

CC @thecrypticace

I don't notice anything that could be in context nor any use of nestedBrackets() (dead code?) that would cause one project to be worse here than another.

I do see that getClassCandidates calling defaultExtractor is parsing my javascript files, but I think that's expected. I see candidates = [ "import", "as", "React", "from", "react" ] which I guess is expected too - you cast a pretty broad net?

[thecrypticace]

Yeah this is a built regex but without a reproduction it's going to be very difficult to figure out the source of the slowness.

is parsing my javascript file

We're scanning files for things that might be utilities but we don't parse them per se. That would require parsers for many possible languages, ability to take an AST from each of those languages and potentially reason about how its used, etc…

We have to cast a broad net just because of the sheer number of ways people can write utilities in various languages.

[thecrypticace]

I would definitely try using v4 for this though. Chances are it's going to significantly faster.

[adamwathan]

Can you share your content configuration? Any chance it’s accidentally scanning node_modules or minified JS files?

[JasonKleban]

Yes, not minified but other one-liners like sourcemaps and tsbuildinfo. Not sure about this, but I suspect those long single lines could be especially hard on the regex compared to if they were split up by \n. Or just the nature of those file contents being a sadistic case. Thanks for the feedback!