UITextView Alternative(UITextView Alternative)

 Data.Text.concat是一个O(n+m)操作，其中n和m是要连接的字符串的长度。 这是因为必须分配大小为n + m的新内存缓冲区来存储连接的结果。 
 
 Builder专门针对mappend操作进行了优化。 这是一种廉价的O(1)操作（功能组合，GHC也极好地优化）。 使用Builder您实际上是在构建有关如何生成最终字符串结果的说明，但是延迟实际创建，直到您执行某些Builder -> Text转换。 
 
 要回答您的问题，如果您已经分析了应用程序并发现Text.concat在运行时占主导地位，则应选择Builder 。 这显然取决于您的需求和应用。 什么时候应该使用Builder没有通用规则，但对于简短的Text文字，可能没有必要。 
 
 如果使用Builder将涉及“进行大规模重构”，那么分析肯定是值得的。 虽然不言而喻，Haskell自然会使这种重构比你习惯使用开发人员友好的语言少得多，所以它可能并不是一项艰巨的任务。 

Data.Text.concat is an O(n+m) operation where n and m are the lengths of the strings you want to concat. This is because a new memory buffer of size n + m must be allocated to store the result of the concatenation.
 
Builder is specifically optimized for the mappend operation. It's a cheap O(1) operation (function composition, which is also excellently optimized by GHC). With Builder you are essentially building up the instructions for how to produce the final string result, but delaying the actual creation until you do some Builder -> Text transformation.
 
To answer your questions, you should choose Builder if you have profiled your application and discovered that Text.concat are dominating the run time. This will obviously depend on your needs and application. There is no general rule for when you should use Builder but for short Text literals there is probably no need.
 
Profiling would definitely be worthwhile if using Builder would involve "undertaking a large-scale refactoring". Although it goes without saying that Haskell will naturally make this kind of refactoring much less painful than you might be used to with less developer friendly languages, so it might not be such a difficult undertaking after all.