v3 generator: optimize hasdoc function to avoid full string scan

[wucm667]

Is your feature request related to a problem? Please describe.

The hasdoc function in v3/internal/generator/render/doc.go uses strings.ContainsFunc to check if a comment group contains any non-whitespace character:

func hasdoc(group *ast.CommentGroup) bool {
    if group == nil {
        return false
    }
    // TODO: this is horrible, make it more efficient?
    return strings.ContainsFunc(group.Text(), func(r rune) bool { return !unicode.IsSpace(r) })
}

For large files with extensive documentation comments, this scans the entire comment text byte-by-byte just to determine if it contains any content beyond whitespace. The TODO comment in the source already acknowledges this inefficiency.

Describe the solution you would like

Replace the full-string scan with an early-return approach:

func hasdoc(group *ast.CommentGroup) bool {
    if group == nil {
        return false
    }
    for _, c := range group.List {
        text := strings.TrimSpace(c.Text)
        if len(text) > 0 {
            return true
        }
    }
    return false
}

This iterates over individual comment entries and returns true as soon as it finds any non-empty comment, avoiding scanning the full concatenated text.

Alternatively, use strings.IndexFunc which also short-circuits on the first match:

return strings.IndexFunc(group.Text(), func(r rune) bool { return !unicode.IsSpace(r) }) != -1

Describe alternatives you have considered

• Keep the current implementation (acceptable for small projects, but suboptimal for large codebases with extensive documentation)
• Cache the result if hasdoc is called multiple times on the same comment group

Additional context

This function is registered as a template function in v3/internal/generator/render/functions.go and is used during Go-to-TypeScript binding generation. For projects with large interfaces or many documented methods, this function may be called repeatedly during code generation.

[fbbdev]

Hello @wucm667 ,

original author of the binding generator here.

Replace the full-string scan with an early-return approach:

Unfortunately the solution you propose won't work, because group.Text() performs a lot of normalisations (see linked snippet) that we need for correct matching and that would be lost if we matched directly on group.List[i].Text.

Reimplementing those normalizations ourselves is IMO quite risky compared to the expected performance gain..

Alternatively, use strings.IndexFunc which also short-circuits on the first match

strings.ContainsFunc short-circuits on the the first match as well, it's actually a wrapper around string.IndexFunc :)

Cache the result if hasdoc is called multiple times on the same comment group

That could do! In fact, the actual performance issue is that we call group.Text() multiple times on the same comment group. However, that should never happen more than 3 times per group, for at most 2-3 groups in parallel. Hence a 3-bucket LRU cache for group texts should solve the issue.

But given the added complexity, I think it would be important to first make sure we have real-world codebases where this function is seriously bottlenecking the generator. Curious to know whether you are hitting such a case.

Consider also that the function would only affect methods/models/packages exported as bindings, not necessarily the whole codebase. And in order to hit a bottleneck, you'd need not just a LOT of exported methods, but most of them should have incredibly large docs as well...

[leaanthony]

@wucm667 Is this to address a theoretical concern or are you hitting bottlenecks in your own code bases?

[leaanthony]

Triage notes:

• Classification: Enhancement (v3) — Optimization proposal for hasdoc template function
• Labels proposed: Enhancement, v3
• Action: Comment-only — the original binding generator author (@fbbdev) has already responded noting the proposed fix won't work correctly. A maintainer (@leaanthony) asked whether this is a theoretical or practical concern. No response yet. Waiting for the reporter to clarify if they're hitting actual bottlenecks.

[wucm667]

Thanks for the responses @fbbdev and @leaanthony.

To answer your question @leaanthony — this is more of a theoretical concern. I noticed the TODO comment about the inefficiency and thought an early-return approach could help, but I haven't actually benchmarked or hit any real bottlenecks in production. Given that @fbbdev explained why the proposed fix would break the normalization that group.Text() provides, the current implementation is probably fine in practice.

Feel free to close this or mark it as low priority if the optimization isn't critical.