Opened 2 years ago

Last modified 2 hours ago

#11382 new bug

Optimize Data.Char

Reported by: bgamari Owned by:
Priority: normal Milestone: 8.6.1
Component: Core Libraries Version: 7.10.3
Keywords: newcomer Cc: ekmett, dfeuer
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: #9638, #1473 Differential Rev(s):
Wiki Page:

Description

Many of the predicates in Data.Char do full Unicode category lookups which turns out to be quite expensive. Ideally we would handle some of the more common ASCII characters with cheaper tests before falling back to the full Unicode treatment.

Change History (7)

comment:1 Changed 2 years ago by ekmett

Didn't David Feuer try some things along this line?

I seem to recall the branching overhead to split off the ASCII cases was hard to overcome in practice.

comment:2 Changed 2 years ago by thomie

Cc: dfeuer added

comment:3 Changed 2 years ago by bgamari

Thanks for the reference, thomie. It looks like David has done some good work in this area already.

This is an area where improvements in branchless boolean operations (#9661) may help.

comment:4 Changed 15 months ago by bgamari

Milestone: 8.2.18.4.1

This won't happen for 8.2; bumping to 8.4.

comment:5 Changed 4 weeks ago by bgamari

Keywords: newcomer added
Milestone: 8.4.1

comment:6 Changed 4 weeks ago by bgamari

Milestone: 8.6.1

This ticket won't be resolved in 8.4; remilestoning for 8.6. Do holler if you are affected by this or would otherwise like to work on it.

comment:7 Changed 2 hours ago by sjakobi

Note: See TracTickets for help on using tickets.