Profiling also confirms my observations: over 20k per call and 0.5 ms per call. Not much per se, but it really adds up when making hundreds or even thousands of links like I do.

Part of this might come from hooks: Translate and SemanticForms are using hooks in linker.

Version: 1.21.x
Severity: normal
URL: http://translatewiki.net/w/profileinfo.php?filter=Linker%3A%3A&sort=time&expand=%2CLinker%3A%3Alink

Details

Reference: bz41377

Related Objects

Mentioned In: T145474: xhgui timing out

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:14 AM

• bzimport added projects: MediaWiki-General, Performance Issue.

• bzimport set Reference to bz41377.

• bzimport added a subscriber: Unknown Object (MLST).

Nikerabbit created this task.Oct 25 2012, 9:40 AM

It looks like the hooks are not a major source of inefficiency:

http://translatewiki.net/w/profileinfo.php?filter=SpecialMyLanguage%3A%3Alinkfix
http://translatewiki.net/w/profileinfo.php?filter=SFFormLinker%3A%3AsetBrokenLink

We should probably put real profiling around those hook calls. Or do we do that implicitly?

All hook calls are profiled, you just need to know the name of the hooked-up functions to search for them.

Sounds unreliable. We should also profile whole combined calls for separation from the surrounding function.

We've got another bit of profiling there for the known stuff that does db calls. How long does that take?

Can we close this since @Legoktm deprecated this static function.

I have not done any intense profiling of LinkRenderer, so it's possible this performance problem still exists. It doesn't appear that https://translatewiki.net/w/profileinfo.php works anymore though?

I only enable profiling when I'm profiling something, and that hasn't happened again since the whole profiling thing changed :). Besides, the hottest paths using Linker::link were already replaced earlier to construct links manually. Also HHVM might have changed the situation considerably.

Legoktm mentioned this in T145474: xhgui timing out.Sep 12 2016, 10:43 PM

Okay, I'll mark it for stalled now. Though now that I've read the above patch, I'm not very surprised that if you call Linker:link() 5000 times it's rather slow. Each call (back then) probably had 10-15 function calls, so times 5000 that would be 50000 function calls, and if you can skip all of those, it would be substantially faster.

Declining for know as I'm not aware of current user-facing performance issues involving this method. In general, the majority of the code base is not critical for performance and if one were to take any of those parts of an extreme, a bottleneck will likely emerge. If and when that happens, we have to trade finding a way to optimise the method general, develop alternate means for that use case (e.g. batching), or to decide it isn't for that purpose and re-approach the original use case.

In this case, given in the last 7 years, this one page for the Translate extension appears to have been the only case where this was an issue, a local workaround was used. Which seems adequate. If this workaround becomes problematic or if the need arises elsewhere, feel free to re-open and reach out to Core Platform and/or Performance for help.

Linker::link is inefficientClosed, DeclinedPublicActions

Description

Details

Related Objects

Event Timeline

Linker::link is inefficient
Closed, DeclinedPublic
Actions