[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends
https://issues.dlang.org/show_bug.cgi?id=13348 Steven Schveighoffer changed: What|Removed |Added CC||dmitry.o...@gmail.com Summary|std.uni.byGrapheme is |std.uni.Grapheme is impure |impure |due to using C malloc and ||friends --- Comment #6 from Steven Schveighoffer --- OK, so pretty much all the problems stem from malloc/realloc/free being used to manage the memory of the Grapheme type. There is one obvious fix: isRegionalIndicator can be marked pure nothrow. we could move the allocation scheme to use the GC instead of C malloc. But I don't know what this does for performance. As the comments say, most uses will never use the allocation. CC Dmitry. --
[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends
https://issues.dlang.org/show_bug.cgi?id=13348 --- Comment #7 from Dmitry Olshansky --- > OK, so pretty much all the problems stem from malloc/realloc/free being used > to manage the memory of the Grapheme type. Should I just use GC? --
[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends
https://issues.dlang.org/show_bug.cgi?id=13348 --- Comment #8 from hst...@quickfur.ath.cx --- Here's a thought, I don't know how feasible it is, but what about using slices of the input string, and decode on demand? Of course, this doesn't work for general input ranges (have to allocate somehow in that case), but conceivably it could be done for ranges with hasSlicing? Or, for forward ranges, use .save. Obviously, this will depend on whether .save allocates, but then it's the user's problem, not ours. The advantage is that we don't have to allocate at all, at least in some cases. The disadvantage is that you'll need to decode again every time grapheme members are accessed. It may cause poor performance. --
[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends
https://issues.dlang.org/show_bug.cgi?id=13348 --- Comment #9 from Steven Schveighoffer --- (In reply to Dmitry Olshansky from comment #7) > Should I just use GC? At this point, if we were to fix purity, I think this is the way to go. From your comments in the code, you said that most of the time allocations will not happen. I'm sure this varies with the language being processed, but it's probably mostly true. One other nice benefit about using the GC is you can remove the requirement to copy the current grapheme if it's on the heap (and make that immutable also, so Grapheme can be passed to another thread if the wrapped range allows it), and copying the struct itself would be less expensive. If we were to wait for pure-compatible reference counting to materialize, this would be the ideal mechanism. (In reply to hsteoh from comment #8) > Here's a thought, I don't know how feasible it is, but what about using > slices of the input string, and decode on demand? Not a big fan of this idea. It puts extra demand on the wrapped range type (must be sliceable or at least forward range), and might make things slower in the case where the stack-allocated part of the union would be sufficient. --
[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends
https://issues.dlang.org/show_bug.cgi?id=13348 greensunn...@gmail.com changed: What|Removed |Added CC||greensunn...@gmail.com --- Comment #10 from greensunn...@gmail.com --- >> Should I just use GC? > At this point, if we were to fix purity, I think this is the way to go. From > your comments in the code, you said that most of the time allocations will > not happen. I'm sure this varies with the language being processed, but it's > probably mostly true. How about doing a simple benchmark with a multi-lingual text and see whether there's any performance difference? --
[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends
https://issues.dlang.org/show_bug.cgi?id=13348 --- Comment #11 from Dmitry Olshansky --- > At this point, if we were to fix purity, I think this is the way to go. From > your comments in the code, you said that most of the time allocations will > not happen. I'm sure this varies with the language being processed, but it's > probably mostly true. Problem is there is @nogc crowd and then there is pure @safe crowd. I can't satisfy both. --
[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends
https://issues.dlang.org/show_bug.cgi?id=13348 --- Comment #12 from Steven Schveighoffer --- (In reply to Dmitry Olshansky from comment #11) > > At this point, if we were to fix purity, I think this is the way to go. > > From your comments in the code, you said that most of the time allocations > > will not happen. I'm sure this varies with the language being processed, > > but it's probably mostly true. > > Problem is there is @nogc crowd and then there is pure @safe crowd. I can't > satisfy both. Haha! good point. Until we have allocator being configurable, we can't solve both. I say leave it the way it is until we have that. @nogc is currently way more important than purity I think, and breaking existing @nogc code by making the default all of a sudden use gc, would be disruptive. --
[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends
https://issues.dlang.org/show_bug.cgi?id=13348 --- Comment #13 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/187e2b769b7ab1e2509d54e31cddc007b423fc8a fix issue 13348 https://github.com/dlang/phobos/commit/fde471f8f21182b875bfbe0a6fdcef58bfa77c78 Merge pull request #5723 from DmitryOlshansky/fix-issue-13348 Fix issue 13348 - byGrapheme is not pure merged-on-behalf-of: unknown --
[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends
https://issues.dlang.org/show_bug.cgi?id=13348 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends
https://issues.dlang.org/show_bug.cgi?id=13348 --- Comment #14 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/187e2b769b7ab1e2509d54e31cddc007b423fc8a fix issue 13348 https://github.com/dlang/phobos/commit/fde471f8f21182b875bfbe0a6fdcef58bfa77c78 Merge pull request #5723 from DmitryOlshansky/fix-issue-13348 --
[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends
https://issues.dlang.org/show_bug.cgi?id=13348 --- Comment #15 from github-bugzi...@puremagic.com --- Commits pushed to dmd-cxx at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/187e2b769b7ab1e2509d54e31cddc007b423fc8a fix issue 13348 https://github.com/dlang/phobos/commit/fde471f8f21182b875bfbe0a6fdcef58bfa77c78 Merge pull request #5723 from DmitryOlshansky/fix-issue-13348 --
