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

Chart having a category with a very (!) long name takes minutes to load #5009

Closed
LionelMarbot opened this Issue Feb 5, 2016 · 6 comments

Comments

Projects
None yet
4 participants
@LionelMarbot

LionelMarbot commented Feb 5, 2016

Hi,

Here is a chart with a relatively long category name: http://jsfiddle.net/fnhktf82/
No problem, everything works fine.

Here is the same chart, just with an even longer category name: http://jsfiddle.net/fnhktf82/2/
Takes minutes to load, in every browser we tested.

It seems to happen, when a certain length is hit.

Any ideas?

Best,
Lionel

@TorsteinHonsi

This comment has been minimized.

Show comment
Hide comment
@TorsteinHonsi

TorsteinHonsi Feb 9, 2016

Collaborator

It seems like problem in the buildText method, where the number of iterations grows exponentially as the number of words increase. We have experimented with a faster way of breaking text, but this work is still inly experimantal.

The best workaround for now is that your setup makes sure to not pass that long texts to the categories.

Collaborator

TorsteinHonsi commented Feb 9, 2016

It seems like problem in the buildText method, where the number of iterations grows exponentially as the number of words increase. We have experimented with a faster way of breaking text, but this work is still inly experimantal.

The best workaround for now is that your setup makes sure to not pass that long texts to the categories.

@TorsteinHonsi TorsteinHonsi added the Bug label Feb 9, 2016

@LionelMarbot

This comment has been minimized.

Show comment
Hide comment
@LionelMarbot

LionelMarbot Aug 28, 2018

Is there any update on this? We are still facing this issue in v6.1.1.

LionelMarbot commented Aug 28, 2018

Is there any update on this? We are still facing this issue in v6.1.1.

@KacperMadej

This comment has been minimized.

Show comment
Hide comment
@KacperMadej

KacperMadej Aug 29, 2018

Contributor

Hi @LionelMarbot

As a workaround you could set useHTML for axis labels to true.

The problem: ~5 seconds to render
http://jsfiddle.net/BlackLabel/grfvadp7/

The workaround: <0.2 seconds to render
http://jsfiddle.net/BlackLabel/grfvadp7/1/

Contributor

KacperMadej commented Aug 29, 2018

Hi @LionelMarbot

As a workaround you could set useHTML for axis labels to true.

The problem: ~5 seconds to render
http://jsfiddle.net/BlackLabel/grfvadp7/

The workaround: <0.2 seconds to render
http://jsfiddle.net/BlackLabel/grfvadp7/1/

@BrianLaughlan

This comment has been minimized.

Show comment
Hide comment
@BrianLaughlan

BrianLaughlan Sep 11, 2018

@KacperMadej I tried to use your workaround with useHTML set to true, this causes more problems for me than it solves.

Yes, using that option fixes the drawing bug, but it leaves me with a not so useful html label that does not have the "built in" highcharts ellipsis etc. I tried to use CSS ellipsis, but it is not working properly.

Overflow and label positions are not calculated well (at all?) with HTML labels, you can even see this in your example: https://doc.enuvo.ch/40ac1dc7b2.png

Could someone at Highcharts please give any indication of when this drawing bug might be fixed?

BrianLaughlan commented Sep 11, 2018

@KacperMadej I tried to use your workaround with useHTML set to true, this causes more problems for me than it solves.

Yes, using that option fixes the drawing bug, but it leaves me with a not so useful html label that does not have the "built in" highcharts ellipsis etc. I tried to use CSS ellipsis, but it is not working properly.

Overflow and label positions are not calculated well (at all?) with HTML labels, you can even see this in your example: https://doc.enuvo.ch/40ac1dc7b2.png

Could someone at Highcharts please give any indication of when this drawing bug might be fixed?

@TorsteinHonsi

This comment has been minimized.

Show comment
Hide comment
@TorsteinHonsi

TorsteinHonsi Sep 11, 2018

Collaborator

I'm working on this now, implementing a binary search for line wraps instead of the ineffective linear search. Expecting results tomorrow.

Collaborator

TorsteinHonsi commented Sep 11, 2018

I'm working on this now, implementing a binary search for line wraps instead of the ineffective linear search. Expecting results tomorrow.

@TorsteinHonsi

This comment has been minimized.

Show comment
Hide comment
@TorsteinHonsi

TorsteinHonsi Sep 12, 2018

Collaborator

The commits above improve the performance of multiline text in two ways:

  • Instead of a linear search for the amount of words that fit into a line, it now runs a binary search. Also, redundant code was removed since this could be combined with the way a string is truncated to apply ellipsis.
  • Instead of adding tspans to the text node and running getBBox, add the whole text string, run getSubStringLength as a binary search, then update the tspan with the resulting text length. This way, the tspan is populated only twice for each line, and the appropriate line length is identified by the fast getSubStringLength function. The dead slow getBBox function doesn't run at all.

Results

  • The original post's jsFiddle previously rendered in 63 seconds in Chrome. It now renders in 290 milliseconds.
  • Kacper's 5-second chart rendered for me in 2400 milliseconds in Chrome. Now it takes 120.
  • In Firefox the improvement is greater. It was slower than Chrome before the changes, but now it is on par.
  • Safari is generally slower but the relative improvement the same as Chrome.
  • In Edge, Kacper's test goes from 13.7 seconds to 670 ms.
Collaborator

TorsteinHonsi commented Sep 12, 2018

The commits above improve the performance of multiline text in two ways:

  • Instead of a linear search for the amount of words that fit into a line, it now runs a binary search. Also, redundant code was removed since this could be combined with the way a string is truncated to apply ellipsis.
  • Instead of adding tspans to the text node and running getBBox, add the whole text string, run getSubStringLength as a binary search, then update the tspan with the resulting text length. This way, the tspan is populated only twice for each line, and the appropriate line length is identified by the fast getSubStringLength function. The dead slow getBBox function doesn't run at all.

Results

  • The original post's jsFiddle previously rendered in 63 seconds in Chrome. It now renders in 290 milliseconds.
  • Kacper's 5-second chart rendered for me in 2400 milliseconds in Chrome. Now it takes 120.
  • In Firefox the improvement is greater. It was slower than Chrome before the changes, but now it is on par.
  • Safari is generally slower but the relative improvement the same as Chrome.
  • In Edge, Kacper's test goes from 13.7 seconds to 670 ms.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment