Example profile data given by @Anomie:

Scribunto_LuaSandboxCallback::callParserFunction		1560 ms	45.1%
Scribunto_LuaSandboxCallback::getEntity		580 ms	16.8%
Scribunto_LuaSandboxCallback::gsub		320 ms	9.2%
Scribunto_LuaSandboxCallback::addStatementUsage		300 ms	8.7%
?		100 ms	2.9%
Scribunto_LuaSandboxCallback::preprocess		100 ms	2.9%
recursiveClone	<mwInit.lua:41>	60 ms	1.7%
Scribunto_LuaSandboxCallback::getExpandedArgument		60 ms	1.7%
Scribunto_LuaSandboxCallback::getFileInfo		40 ms	1.2%
Scribunto_LuaSandboxCallback::fullUrl		40 ms	1.2%
[others]		300 ms	8.7%

@Anomie question, why is frame:: extensionTag expensive and why would a direct call into kartographer be less expensive ?

In T189769#6042901, @TheDJ wrote:

@Anomie question, why is frame:: extensionTag expensive

It's not expensive in the sense of counting towards the "expensive parser function count" limit.

It may be "expensive" in that it goes through Parser::callParserFunction() instead of doing something more direct. But whether doing something more direct would actually be appreciably faster I don't know. The time attributed to "Scribunto_LuaSandboxCallback::callParserFunction" in the trace in T189769#4052824 doesn't (and can't) break down what part of that time is spent in callParserFunction() versus in Kartographer itself.

Yeah as I suspected. I doubt going directly in the tag logic of Kartographer is actually that much faster. Both are bridges into a tagfunction, one just specifies a specific tag function.

So I suspect the most expensive parts are:
1: json parsing of the kartographer features
2: storing json of the kartographer features
3: wikitext parsing of the properties of features
4: wikitext parsing of the maplink contents/mapframe 'text'

I guess we can specify that the content passed needs to be already preprocessed if you want to use wikitext, thereby bypassing the internal parser run most of the time...?