Opened 5 years ago

Last modified 4 years ago

#9542 new task

GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring

Reported by: dfeuer Owned by:
Priority: normal Milestone:
Component: Core Libraries Version: 7.8.2
Keywords: fusion, refactoring Cc: hvr, ekmett
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


The boundary between writeBlocks and hPutStr' looks badly drawn, with pieces of buffering type on either side. I would also speculate that one or more CRLF-related helper functions may be in order.

Change History (6)

comment:1 Changed 5 years ago by dfeuer

Summary: GHC-IO-Handle-Text.hputStr' and writeBlocks look like they need refactoringGHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring

We probably also want to make sure that hPutStr', writeBlocks, and/or whatever other pieces are inlined into hPutStr and hPutStrLn to avoid unnecessary tests for add_nl.

comment:2 Changed 5 years ago by dfeuer

There are probably actually some list fusion opportunities in this area these days. hPutChars is apparently low-performance anyway, but I think it might as well be written

hPutChars :: Handle -> [Char] -> IO ()
hPutChars handle = mapM_ (hPutChar handle)

More importantly, I would conjecture that we can probably fuse writeBlocks. Call Arity seems to allow a fusing foldM, and writeBlocks seems to have that general structure. The devil may have details, of course.

comment:3 Changed 5 years ago by dfeuer

Keywords: fusion refactoring added

Indeed, writeBlocks can be written as a foldM form, which can fuse, at least in theory. It may, however, be a challenge to bend arity analysis to my will without inlining more than we should. This may or may not be compounded by the fact that in tearing apart writeBlocks I realized that there's a special case buried within: block buffering with normal (non-Windows) end-of-line conventions never actually needs to examine the characters it handles. I would venture to guess that we could exploit that fact to improve efficiency.

comment:4 Changed 5 years ago by thoughtpolice

Component: libraries/baseCore Libraries
Owner: set to ekmett

Moving over to new owning component 'Core Libraries'.

comment:5 Changed 4 years ago by thomie

Owner: ekmett deleted

comment:6 Changed 4 years ago by thomie

Type of failure: None/UnknownRuntime performance bug
Note: See TracTickets for help on using tickets.