Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert more uses of String to Text. #1281

Merged
merged 1 commit into from
Apr 30, 2021
Merged

Convert more uses of String to Text. #1281

merged 1 commit into from
Apr 30, 2021

Conversation

brianhuffman
Copy link
Contributor

This helps with #1269, removing several occurrences of Text.unpack.

@@ -1439,7 +1440,7 @@ setupArg sc sym ecRef tp = do
freshGlobal cty sc_tp =
do ecs <- readIORef ecRef
let len = Seq.length ecs
ec <- scFreshEC sc ("arg_"++show len) sc_tp
ec <- scFreshEC sc ("arg_" <> Text.pack (show len)) sc_tp
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two calls to Text.pack here, one of which is implicit in the use of OverloadedStrings. This can be shaved down to just one:

Suggested change
ec <- scFreshEC sc ("arg_" <> Text.pack (show len)) sc_tp
ec <- scFreshEC sc (Text.pack ("arg_" ++ show len)) sc_tp

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had assumed that any calls to Text.pack arising from OverloadedStrings would be constant-folded away by the compiler; is this not the case? I was actually thinking that the obvious next improvement for this line would be to find a replacement for pack . show.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought I recalled pack being a performance bottleneck, but now that I look closer, that's for ByteString's pack, not Text's pack.

Both versions will constant-fold the "arg_" part, so I suppose it's just a question of whether it's faster to append two strings and pack them at the end, or to pack two strings and them append them in the end. But for strings this small, it seems very unlikely to matter.

tl;dr Go with whichever style looks better to you.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of minimizing the number of subexpressions of type String, so if the performance is about the same, I'll just keep it as is.

@@ -202,7 +202,7 @@ buildArg arg idx
$ arg ^. argSkelType . typeSkelLLVMType
pure (Just val, Nothing, arg ^. argSkelName)
where
ident = maybe ("arg" <> show idx) Text.unpack $ arg ^. argSkelName
ident = maybe ("arg" <> Text.pack (show idx)) id $ arg ^. argSkelName
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
ident = maybe ("arg" <> Text.pack (show idx)) id $ arg ^. argSkelName
ident = maybe (Text.pack ("arg" ++ show idx)) id $ arg ^. argSkelName

@@ -237,7 +237,7 @@ rebuildArg (arg, prearg) idx
-> LLVM.Array (fromIntegral $ s ^. sizeGuessElems) pt
| otherwise -> pt
_ -> pt
ident = maybe ("arg" <> show idx) Text.unpack nm
ident = maybe ("arg" <> Text.pack (show idx)) id nm
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
ident = maybe ("arg" <> Text.pack (show idx)) id nm
ident = maybe (Text.pack ("arg" ++ show idx)) id nm

@brianhuffman brianhuffman added the ready-to-merge If at least one person approves this PR, automatically merge it when CI finishes successfully. label Apr 30, 2021
@mergify mergify bot merged commit 2e4fc06 into master Apr 30, 2021
@mergify mergify bot deleted the string-text branch April 30, 2021 19:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-to-merge If at least one person approves this PR, automatically merge it when CI finishes successfully.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants