Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/text/unicode/bidi: consider reusing internal slices #67098

Open
benoitkugler opened this issue Apr 28, 2024 · 1 comment
Open

x/text/unicode/bidi: consider reusing internal slices #67098

benoitkugler opened this issue Apr 28, 2024 · 1 comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@benoitkugler
Copy link

Go version

go version 1.22

Output of go env in your module/workspace:

Non relevant

What did you do?

In go-text/typesetting, we use bidi to segment the input text. We store and reuse one bidi.Paragraph object, calling its SetString method for each new input.

What did you see happen?

The bidi.Paragraph.prepareInput method has high memory allocation.

What did you expect to see?

Only few allocations. If possible, the slices pairTypes, pairValues, types should reuse their capacity (instead of being freed and immediately re-allocated).

On the same topic, paragraph.determineLevelRuns allocates a new run []int slice, but it is perhaps harder to get rid of this allocation.

@gopherbot gopherbot added this to the Unreleased milestone Apr 28, 2024
@mauri870 mauri870 added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 1, 2024
@mauri870
Copy link
Member

mauri870 commented May 1, 2024

Friendly ping @mpvl per https://dev.golang.org/owners

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

3 participants