Opened 2 years ago

Closed 3 months ago

#11382 closed bug (wontfix)

Optimize Data.Char

Reported by: bgamari Owned by:
Priority: normal Milestone:
Component: Core Libraries Version: 7.10.3
Keywords: newcomer Cc: ekmett, dfeuer, lelf
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 (9)

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 19 months ago by bgamari

Milestone: 8.2.18.4.1

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

comment:5 Changed 5 months ago by bgamari

Keywords: newcomer added
Milestone: 8.4.1

comment:6 Changed 5 months 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 4 months ago by sjakobi

comment:8 Changed 4 months ago by lelf

Cc: lelf added

comment:9 Changed 3 months ago by bgamari

Milestone: 8.6.1
Resolution: wontfix
Status: newclosed

Given the findings in ticket:9638#comment:4, I'm going to close this for now. I, for one, don't have time to look into this at the moment.

Note: See TracTickets for help on using tickets.