[GHC] #9542: GHC-IO-Handle-Text.hputStr' and writeBlocks look like they need refactoring
#9542: GHC-IO-Handle-Text.hputStr' and writeBlocks look like they need refactoring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9542 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9542: GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): 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`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9542#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9542: GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (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 {{{#!hs 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9542#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9542: GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: fusion, Resolution: | refactoring Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * keywords: => fusion, refactoring Comment: 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9542#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC