[GHC] #9577: String literals are wasting space
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For [https://phabricator.haskell.org/D199 D199] I looked into how string literals are compiled down by GHC. On 64-bit OS X, a simple string `"AAA"` turns into assembly: {{{ .const .align 3 .align 0 c38E_str: .byte 65 .byte 65 .byte 65 .byte 0 }}} (And also something that invokes `unpackCString#`, but that isn't relevant here.) (`MkCore.mkStringExprFS` -> `CmmUtils.mkByteStringCLit` -> `compiler/nativeGen/X86/Ppr.pprSectionHeader`.) Note how this: * Is 8 byte aligned. * Is a `.const` section. I can't find any reason why string literals would need to be 8-byte aligned on OS X. There might be a small benefit in performance to read data starting 8-byte aligned, but I doubt doing that for string literals would be a meaningful difference. Assembly from both clang and gcc does not align string literals. The trivial program: {{{#!hs main :: IO () main = return () }}} has almost 5kB of wasted space of padding between all strings the Prelude brings in, built with GHC HEAD. The fact that it is a `.const` section, instead of `.cstring` (https://developer.apple.com/library/mac/documentation/DeveloperTools/Referen...) means duplicate strings aren't shared by the assembler. GHC floats out string literals to the top-level and uses CSE to eliminate duplicates, but that only works in a single modules. Strings shared between different modules end up as duplicate strings in an executable. The same program as above also has ~4kB of wasted space due to duplicate Prelude strings (`"base"` occurs 16 times!). Compared to the total binary size (4MB after stripping), removing this redundant data wouldn't be a big improvement (0.2%), but I still think it can be a worthwile optimization. I think this can be solved quite easily by creating a new section header for literal strings, which is unaligned and of type `.cstring`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by xnyhps): * owner: => xnyhps -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): You sound as if you know what you are talking about. I say go for it! But please make sure that whatever you do works on Windows and Linux as well as Mac. Thanks! Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by xnyhps): Yeah, I have Windows and Linux available to test on. Other architectures (PPC/ARM/...) not as easily, so I'll keep the generated code for those unchanged. Gathering up some discussion from GCC about alignment of string literals: * https://gcc.gnu.org/ml/gcc/2002-01/msg01068.html * https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02835.html: {{{ * config/i386/i386.c (ix86_constant_alignment): Decrease alignment of long string literals from 32 bytes to sizeof (void *) when !-Os and to 1 with -Os. }}} * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158 The main argument in favor of alignment seems to be: code often `memcpy`s string literals into buffers. By doing that with aligned addresses (apparently) SSE instructions can be used. This is irrelevant for GHC, because the strings are only parsed into `[Char]`s, never copied. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 xnyhps]:
The main argument in favor of alignment seems to be: code often `memcpy`s string literals into buffers. By doing that with aligned addresses (apparently) SSE instructions can be used. This is irrelevant for GHC, because the strings are only parsed into `[Char]`s, never copied.
Will that always be the case if a string literal represents something like `Text` or `ByteString`? If so, will that continue to hold in the future? Might a future optimization fuse `putStr` with the conversion to do a copy? It may be that these concerns are baseless, but it might make sense to consider what alternative optimizations yours could preclude. You mention that there are a lot of string literals in the Prelude. I would bet that the vast majority of those are error messages. Might it be possible to specifically target ''exceptional'' strings that should never be anywhere speed-critical, and pack them all together? Putting them all together, ideally starting or ending on a page boundary, would (hopefully) mean that they wouldn't even need to be swapped in unless an error occurred. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): Replying to [comment:3 xnyhps]:
The main argument in favor of alignment seems to be: code often `memcpy`s string literals into buffers. By doing that with aligned addresses (apparently) SSE instructions can be used. This is irrelevant for GHC, because the strings are only parsed into `[Char]`s, never copied.
We avoid going via `[Char]` when creating `ByteString` literals already today (using RULES). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
Replying to [comment:3 xnyhps]:
The main argument in favor of alignment seems to be: code often `memcpy`s string literals into buffers. By doing that with aligned addresses (apparently) SSE instructions can be used. This is irrelevant for GHC, because the strings are only parsed into `[Char]`s, never copied.
Will that always be the case if a string literal represents something
You mention that there are a lot of string literals in the Prelude. I would bet that the vast majority of those are error messages. Might it be
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by xnyhps): Replying to [comment:4 dfeuer]: like `Text` or `ByteString`? If so, will that continue to hold in the future? Might a future optimization fuse `putStr` with the conversion to do a copy? It may be that these concerns are baseless, but it might make sense to consider what alternative optimizations yours could preclude. For the record, this is the rewrite rule used by ByteString: * https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.h..., calling https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.h.... This just wraps the `Addr#` directly, no copying here. However, [https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.h... append] does call `memcpy` twice. I don't think GHC has the kind of optimizations that can turn a `memcpy` call into SIMD instructions directly, but maybe `memcpy` is more efficient when called with aligned buffers. I'll try to test this. And these are the rewrite rules for text: * https://github.com/bos/text/blob/e33c89be4256fdd1c31f39d8a2a63e58e23b0182/Da... calling https://github.com/bos/text/blob/e33c89be4256fdd1c31f39d8a2a63e58e23b0182/Da... A loop similar to `unpackCString#`, so alignment won't matter much. It is true that we might find optimizations later that benefit from aligned strings. But unaligning them now doesn't preclude that. Literals only exist within a single module, so any optimization has control over both the literal and the code that uses it. (`Strings` can be exported, but `Addr#`s can't.) Even if someone would try to mix object files generated by different versions of GHC it wouldn't be a problem. possible to specifically target ''exceptional'' strings that should never be anywhere speed-critical, and pack them all together? Putting them all together, ideally starting or ending on a page boundary, would (hopefully) mean that they wouldn't even need to be swapped in unless an error occurred. I'm not familiar enough with assembly or executable file formats to say whether this is possible, but I'll keep it in mind. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
For the record, this is the rewrite rule used by ByteString:
* https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.h..., calling https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.h....
This just wraps the `Addr#` directly, no copying here. However, [https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.h... append] does call `memcpy` twice. I don't think GHC has the kind of optimizations that can turn a `memcpy` call into SIMD instructions
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): Replying to [comment:6 xnyhps]: directly, but maybe `memcpy` is more efficient when called with aligned buffers. I'll try to test this. The memcpy implementation (used by e.g. `copyByteArray#`) does unroll memcpys of statically known size and alignment, if aligned to a word, so I definitely think we should try to align our data that way. In 7.10 (if Phab:D166 goes in) we'll do even better and use a `REP-MOVSB` instruction on Ivy bridge and newer. `REP-MOVSB` is almost as fast as an unrolled AVX loop. The memcpy unrolling is implemented in source:compiler/nativeGen/X86/CodeGen.hs. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Any `memcpy` of a string will not be a statically known size. Furthermore, for small strings I think the space we save by not aligning them outweighs any benefit from aligned memcpy. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
Any `memcpy` of a string will not be a statically known size. Furthermore, for small strings I think the space we save by not aligning
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): Replying to [comment:8 simonmar]: them outweighs any benefit from aligned memcpy. Why not? With OverloadedLists we now desugar list literals (which are really no different than string literals, conceptually) to `fromListN`, so code that creates e.g. a `ByteString` from a list literal can be implemented with a memcpy that has its argument statically known. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by xnyhps): I found #5218, which sounds like a nice solution for bytestrings because it gives the option to do different things with string and bytestring literals (part 2 of [https://ghc.haskell.org/trac/ghc/ticket/5218#comment:3 comment 3]). I can look at this at the same time. Alternatively, using the same heuristic as GCC would also be an option: align only ≥32 byte strings. (`genCCall` has a maximum length it will unroll, but I can't tell what that practically is on x86.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): If I have a server today that serves a large literal ByteString in response to a particular request, presumably that string buffer will get copied out of at some point—maybe even by the kernel. That memcpy probably won't have statically known size or alignment but it probably will determine at runtime that the size is large and alignment is suitable for doing a more efficient copy. Replying to [comment:10 xnyhps]:
Alternatively, using the same heuristic as GCC would also be an option: align only ≥32 byte strings. (`genCCall` has a maximum length it will unroll, but I can't tell what that practically is on x86.)
I think we should just do this (at least for now). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
You mention that there are a lot of string literals in the Prelude. I would bet that the vast majority of those are error messages. Might it be
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:4 dfeuer]: possible to specifically target ''exceptional'' strings that should never be anywhere speed-critical, and pack them all together? Putting them all together, ideally starting or ending on a page boundary, would (hopefully) mean that they wouldn't even need to be swapped in unless an error occurred. I think this is easy to do as far as the linker side of things is concerned (just put the exceptional strings in their own section); the only bit that might be tricky is identifying which string literals should be considered exceptional and plumbing that information through the compiler. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by xnyhps): Documenting what I found about merging duplicate string constants in GCC/clang: Turning on `-fmerge-constants` with GCC changes the generated assembly: {{{ - .section .rodata + .section .rodata.str1.1,"aMS",@progbits,1 }}} As far as I can tell, this stands for: * `a` sets `SHF_ALLOC` * `M` sets `SHF_MERGE` * `S` sets `SHF_STRINGS` * `@progbits` sets `SHT_PROGBITS` * The `1` indicates the size of each entry (character) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:12 rwbarton]:
I think this is easy to do as far as the linker side of things is concerned (just put the exceptional strings in their own section); the only bit that might be tricky is identifying which string literals should be considered exceptional and plumbing that information through the compiler.
I think identifying them shouldn't be too hard (in enough cases to be useful)—they're not exported and they appear only as arguments to `error` or possibly other exception-raising functions. I say possibly because I imagine there may be situations where exceptions that carry strings may need to be handled quickly. I imagine, however, that in those cases the strings themselves may not be inspected. Another thought is that there's probably an open source or public domain block compression algorithm that can fit in a few hundred bytes of slow assembly to access a compressed error string region. Such a thing should of course be optional if we decide to do it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): One question I've got about this whole thread is this: What would this improve? I'm trying to understand how this will impact application performance or binary sizes (though i understand the latter is defnitely neglible) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:15 carter]:
One question I've got about this whole thread is this: What would this improve? I'm trying to understand how this will impact application performance or binary sizes (though I understand the latter is definitely neglible)
Very good question. As someone who knows very little about these issues, it seems to me that there are probably approximately three related issues that will affect performance: 1. Aligning strings to word boundaries seems to be good for all sorts of reasons (comparison, copying, searching, etc.). 2. Arranging for code that (exclusively) uses a string to be likely to bring the beginning of the string in on its cache line should often be good. This kind of thing goes beyond strings, of course, and I have no idea what GHC does about it in general. 3. Dragging an error message fragment in on a cache line should always be bad. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): these are great hypotheses, but the question is "do they make a measurable difference on any code perf?" Are there ways we can measure this without having to do the whole change? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek):
Are there ways we can measure this without having to do the whole change?
Was there ever any optimisation which impact we could measure without implementing it? (I'm asking seriously.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by xnyhps): Replying to [comment:15 carter]:
One question I've got about this whole thread is this: What would this improve? I'm trying to understand how this will impact application performance or binary sizes (though i understand the latter is defnitely neglible)
I think the performance loss for `[Char]`-strings is negligible: sharing means they are going to be unpacked just once, that's not worthy optimizing performance for. After unpacking the literal is never used again. `ByteString`s may have noticeable impact. Prepending a `ByteString` literal onto another `ByteString` involves a `memcpy` of the literal string. There might be code out there that does it millions of times. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | codeGen/should_run/T9577 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1290 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => codeGen/should_run/T9577 * differential: => Phab:D1290 * milestone: => 8.2.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space
-------------------------------------+-------------------------------------
Reporter: xnyhps | Owner: xnyhps
Type: bug | Status: patch
Priority: low | Milestone: 8.2.1
Component: Compiler (NCG) | Version: 7.8.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: Runtime | Test Case:
performance bug | codeGen/should_run/T9577
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D1290
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Ben Gamari
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | codeGen/should_run/T9577 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1290 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space
-------------------------------------+-------------------------------------
Reporter: xnyhps | Owner: xnyhps
Type: bug | Status: closed
Priority: low | Milestone: 8.2.1
Component: Compiler (NCG) | Version: 7.8.2
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: Runtime | Test Case:
performance bug | codeGen/should_run/T9577
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D1290
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Ben Gamari
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | codeGen/should_run/T9577 Blocked By: | Blocking: Related Tickets: #12937, #12965 | Differential Rev(s): Phab:D1290 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #12937, #12965 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9577: String literals are wasting space
-------------------------------------+-------------------------------------
Reporter: xnyhps | Owner: xnyhps
Type: bug | Status: closed
Priority: low | Milestone: 8.2.1
Component: Compiler (NCG) | Version: 7.8.2
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: Runtime | Test Case:
performance bug | codeGen/should_run/T9577
Blocked By: | Blocking:
Related Tickets: #12937, #12965 | Differential Rev(s): Phab:D1290
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Ben Gamari
#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.8.2 Resolution: fixed | Keywords: strings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | codeGen/should_run/T9577 Blocked By: | Blocking: Related Tickets: #12937, #12965 | Differential Rev(s): Phab:D1290 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => strings -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9577#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC