Re: length's type.
On Wednesday, January 17, 2024 11:33:48 PM MST zjh via Digitalmars-d-learn wrote: > On Thursday, 18 January 2024 at 04:30:33 UTC, Jonathan M Davis > wrote: > but for a lot of code, using auto and size_t makes it > > > so that you don't need to use int, and it would be a big > > problem in general if the language made length int. > > It's hard to imagine that an `'int'` needs to be replaced with > `'auto'`. It's very common in D code to do stuff like auto a = foo(); or auto len = arr.length; That way, you automatically get the correct type. Obviously, there are cases where you need to force a particular type, and that can require casting, but inferring types often simplifies code. It's _very_ common in idiomatic D code to use auto when you don't need to force a specific type. And when dealing with arrays, it's very typical to use either auto or size_t, because then you get the correct integer type regardless of the platform, and then you only need to worry about casting to int in cases where you actually need int for whatever reason. But regardless of whether you want to use auto, there are very good reasons for why length is size_t, and C/C++ made exactly the same choice for the same reasons. You can certainly disagree with that choice, but it's not the kind of thing that stands much chance of ever being changed. - Jonathan M Davis
Re: length's type.
On Thursday, 18 January 2024 at 04:30:33 UTC, Jonathan M Davis wrote: but for a lot of code, using auto and size_t makes it so that you don't need to use int, and it would be a big problem in general if the language made length int. It's hard to imagine that an `'int'` needs to be replaced with `'auto'`.
Re: vector crash
On Thursday, 18 January 2024 at 04:24:18 UTC, zjh wrote:
```d
class V : ASTVisitor
{
Vector!string f=[];
alias visit = ASTVisitor.visit;
override void visit(const FunctionDeclaration decl)
{
writeln(' '.repeat(indentLevel * 4), decl.name.text);
f.push_back(decl.name.text);
indentLevel++;
scope (exit) indentLevel--;
decl.accept(this);
}
void out(string s){
string b=s~".t";toF(f,b);
}
}
```
Re: length's type.
On Wednesday, January 17, 2024 7:55:37 PM MST zjh via Digitalmars-d-learn wrote: > Can you change the type of 'length' from 'ulong' to 'int', so I > haven't to convert it every time! If you mean for arrays, length and array indices are specifically size_t so that their size will match the pointer size for the architecture. On 64-bit systems, that means that it's ulong (whereas on 32-bit systems, it would be uint). If it were int, then you couldn't access all of the elements of larger arrays (and arrays will get that large in some cases - e.g. when dealing with larger files). C/C++ does the same thing. If you want your code to be portable and to be able to handle larger arrays, then it should be using size_t for array indices and length and not int, in which case, you're not typically going to need to convert from ulong to int, because you'd just be using size_t, which would then be ulong on 64-bit systems. Obviously, when you do need to convert to int, then that can be annoying, but for a lot of code, using auto and size_t makes it so that you don't need to use int, and it would be a big problem in general if the language made length int. - Jonathan M Davis
Re: vector crash
On Thursday, 18 January 2024 at 04:20:12 UTC, zjh wrote:
foreach(e;d){
```d
foreach(e;d){//.0
string b=e;
string m=readText(b);ff(m,b);
}
```
or here `.0`? why crash?
Re: vector crash
On Thursday, 18 January 2024 at 03:53:09 UTC, Steven
Schveighoffer wrote:
Are you sure this is what you are wanting to do?
-Steve
```d
void gg(string a){
Vector!string d=[];toV(a,d);//File to Vector
print(d);//3,OK
foreach(e;d){
string b=e;//.1
string m=readText(b);ff(m,b);
}
}
```
`gg`: I want to traverse the 'a' file and then call the `ff`
function .
But there was an error with the `vector` here, the file had 3 or
4 lines, but now it crashes on the 3rd line, and when calling
print seperately, the output is normal.
I think that here `b` copied `e`, even if the `ff` function goes
wrong, it won't affect `e`. I really don't know why it crashed at
`.1`?.
Re: vector crash
On Thursday, 18 January 2024 at 03:07:13 UTC, zjh wrote: ```d import dparse.ast; import dparse.lexer; import dparse.parser : parseModule; import dparse.rollback_allocator : RollbackAllocator; import core.stdcpp.vector; import core.stdcpp.string; ... ``` I have no experience with using cpp from D, and I'm not sure exactly what you are trying to do (your code is not complete), but using `string` in this context does not mean C++ std::string, it's a D string (`immutable(char)[]`). Are you sure this is what you are wanting to do? -Steve
Re: vector crash
On Thursday, 18 January 2024 at 03:11:57 UTC, zjh wrote: ```d string b=d[i];//the 3th:vector.d //`+Object`,crashes! ``` ```d //d[i]==>e string b=e; ``` in the foreach.
Re: vector crash
On Thursday, 18 January 2024 at 03:07:13 UTC, zjh wrote: Why can `b` still affect `e` here? Isn't `b` copied? here foreach crashes. Starting from the `third one`, it crashes. It's clearly `vector.d`, but the result is`+Object`. ```d string b=d[i];//the 3th:vector.d //`+Object`,crashes! ```
vector crash
```d
import dparse.ast;
import dparse.lexer;
import dparse.parser : parseModule;
import dparse.rollback_allocator : RollbackAllocator;
import core.stdcpp.vector;
import core.stdcpp.string;
Vector!string d=[];toV(a,d);
print(d);//3
foreach(e;d){
string b=d[i];
string m=readText(b);ff(m,b);
}
void ff(string B,string s)
{
LexerConfig config;
auto cache = StringCache(StringCache.defaultBucketCount);
auto tokens = getTokensForParser(B, config, );
RollbackAllocator rba;
auto m = parseModule(tokens,s, );
auto v= new V();
v.visit(m);v.out(s);
}
```
Why can `b` still affect `e` here? Isn't `b` copied?
here foreach crashes.
Re: hunt-examples/website-basic
On Saturday, 29 April 2023 at 18:05:20 UTC, Vino B wrote: Hi All, Request your help, while trying to compile the hunt-examples/website-basic, I am facing with the below error(https://github.com/huntlabs/hunt-examples/tree/master/website-basic). Error ``` C:\Users\test\AppData\Local\dub\packages\hunt-validation-0.5.0\hunt-validation\source\hunt\validation\DeclDef.d-mixin-41(54,102): Error: undefined identifier `arg` C:\Users\test\AppData\Local\dub\packages\hunt-validation-0.5.0\hunt-validation\source\hunt\validation\DeclDef.d-mixin-41(51,106): Error: undefined identifier `arg` C:\Users\test\AppData\Local\dub\packages\hunt-validation-0.5.0\hunt-validation\source\hunt\validation\DeclDef.d-mixin-41(54,108): Error: undefined identifier `arg` C:\Users\test\AppData\Local\dub\packages\hunt-validation-0.5.0\hunt-validation\source\hunt\validation\DeclDef.d-mixin-41(51,108): Error: undefined identifier `arg` ``` From, Vino.B Maybe, it's a bug in the newer compiler. See https://issues.dlang.org/show_bug.cgi?id=24344. It's fixed in hunt-validation. See https://github.com/huntlabs/hunt-validation/commit/c82f872e1042c80fe20ec85097f9003cc0f310e1
Re: Understanding the Use of Nested Import and Selective Import in D
On Wednesday, January 17, 2024 7:03:18 AM MST Renato via Digitalmars-d-learn wrote: > My main reasoning is that D tools, surprisingly, cannot do > "Optimize Imports" (turns out that with all the metaprogramming > going on , it's impossible to tell for sure which imports are > being used - or so I read in another thread about this topic)... A tool could do it assuming that it's opinionated enough about local imports, and you're willing to let code break if imports that arguably should be local aren't. Otherwise, yeah, you can't really do it in the general case because of conditional compilation. Specifically, the problem is that it's possible to have an import statement which is always compiled into the code but where the symbols from it are only used some of the time. So, for the tool to know which imports are used or not, it would have to somehow be able to hit every conditional branch (from version statements, static if statements, templates, etc.), which isn't really something that can be done. For instance, if you have version statements in your code (e.g. Posix vs Windows), you can have symbols which are used only within a portion of the versioned blocks, but the import is at the top-level and always compiled in. So, if those version statements aren't being compiled in when the tool is run, then it would conclude that the import was unnecessary and remove it, which would then break the code when it's compiled in a situation where those version statements do get compiled in. And of course, the situation is further complicated by the fact that the module being imported could have a different set of symbols depending on conditional compilation. As such, the tool can't really determine for sure that an import isn't used. It _might_ be able to detect whether any code branches depend on conditional compilation and remove unused imports if there aren't any, but with how often conditional compilation is used in typical D code, that's not necessarily very useful, and if you have a situation where one module provides the symbols on one platform, but another module provides them on another platform (which could definitely happen with OS stuff), and both modules are being imported, then even if the module you're checking for unused imports doesn't have conditional compilation, you could still end up removing imports that you shouldn't have due to conditional compilation in the modules being imported. That being said, if the tool is opinionated about local imports, it could be done. Specifically, what it could do is take the stance that all imports that are used in conditionally compiled code must be local (and thus only imported when that code is compiled in), in which case, if it finds an import which isn't actually used, then it can just remove it. That would then break any code that hadn't used local imports to import symbols that were only used within conditionally compiled code, so whether it would really be a desirable tool to have in general would be debatable, but taking that approach should make it possible to have such a tool. Another approach would be to have a linting tool which warned you about possibly unused imports but didn't actually remove any. Since it would be less automatic, it would be more annoying to use, but it would avoid removing imports that were actually used in conditionally compiled code, and if you wanted to get rid of the warning you could make those imports local. Still, you can't really remove all unused imports, because the ones that are conditionally compiled in couldn't be examined properly unless that code was being compiled in, which would potentially require running the tool on a variety of platforms and with a variety of conditions that you wouldn't always run into. So, as is often the case, D's metaprogramming capabiltiies complicate the situation considerably with regards to tooling. - Jonathan M Davis
Re: compute from a string the text of a string literal
On Wednesday, 17 January 2024 at 18:53:48 UTC, Paul Backus wrote:
There's a function that does this in Phobos, but it's
`private`. Currently, the only way to access it is by calling
`to!string` or `format` on a range that contains the string you
want to convert as an element:
```d
void main()
{
import std.range, std.conv, std.stdio;
string s = `"foo"\bar`;
string escaped = only(s).to!string[1 .. $-1]; // slice off
[ and ]
writeln(escaped); // "\"foo\"\\bar"
}
```
Great! I'll use that!
Re: compute from a string the text of a string literal
On Wednesday, 17 January 2024 at 18:44:14 UTC, Carl Sturtivant
wrote:
Hello,
I'd like a function like this,
```
string image(string s)
```
that maps any string s into the doubly quoted backslash escaped
text that would be a string literal for s were it pasted into a
program. Perhaps with a second parameter with detailed options.
Is there something out there I could use?
There's a function that does this in Phobos, but it's `private`.
Currently, the only way to access it is by calling `to!string` or
`format` on a range that contains the string you want to convert
as an element:
```d
void main()
{
import std.range, std.conv, std.stdio;
string s = `"foo"\bar`;
string escaped = only(s).to!string[1 .. $-1]; // slice off [
and ]
writeln(escaped); // "\"foo\"\\bar"
}
```
compute from a string the text of a string literal
Hello, I'd like a function like this, ``` string image(string s) ``` that maps any string s into the doubly quoted backslash escaped text that would be a string literal for s were it pasted into a program. Perhaps with a second parameter with detailed options. Is there something out there I could use?
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wednesday, 17 January 2024 at 16:30:08 UTC, H. S. Teoh wrote: On Wed, Jan 17, 2024 at 07:19:39AM +, Renato via Digitalmars-d-learn wrote: [...] But pls run the benchmarks yourself as I am not going to keep running it for you, and would be nice if you posted your solution on a Gist for example, pasting lots of code in the forum makes it difficult to follow. I can't. I spent half an hour trying to get ./benchmark.sh to run, but no matter what it could not compile benchmark_runner. It complains that my rustc is too old and some dependencies do not support it. I tried running the suggested cargo update command to pin the versions but none of them worked. Since I'm not a Rust user, I'm not feeling particularly motivated right now to spend any more time on this. Upgrading my rustc isn't really an option because that's the version currently in my distro and I really don't feel like spending more time to install a custom version of rustc just for this benchmark. T I've just updated the Rust version to the benchmark monitor could work on Linux (it only worked on Mac before) :D that's probably why your rustc didn't work, though as the project is still using edition2018 I would've thought even a very old compiler would have worked... anyway, if you ever find yourself actually using Rust, you should use `rustup` (https://rustup.rs/) which makes it trivial to update Rust. About the "count" option: I had assumed you didn't call format on the count option as it's never needed, there's nothing to print.
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wed, Jan 17, 2024 at 07:57:02AM -0800, H. S. Teoh via Digitalmars-d-learn wrote: [...] > I'll push the code to github. [...] Here: https://github.com/quickfur/prechelt/blob/master/encode_phone.d T -- Why do conspiracy theories always come from the same people??
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wed, Jan 17, 2024 at 07:19:39AM +, Renato via Digitalmars-d-learn wrote: [...] > But pls run the benchmarks yourself as I am not going to keep running > it for you, and would be nice if you posted your solution on a Gist > for example, pasting lots of code in the forum makes it difficult to > follow. I can't. I spent half an hour trying to get ./benchmark.sh to run, but no matter what it could not compile benchmark_runner. It complains that my rustc is too old and some dependencies do not support it. I tried running the suggested cargo update command to pin the versions but none of them worked. Since I'm not a Rust user, I'm not feeling particularly motivated right now to spend any more time on this. Upgrading my rustc isn't really an option because that's the version currently in my distro and I really don't feel like spending more time to install a custom version of rustc just for this benchmark. T -- Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wed, Jan 17, 2024 at 07:19:39AM +, Renato via Digitalmars-d-learn wrote: > On Tuesday, 16 January 2024 at 22:13:55 UTC, H. S. Teoh wrote: > > used for the recursive calls. Getting rid of the .format ought to > > speed it up a bit. Will try that now... > > > > That will make no difference for the `count` option which is where > your solution was very slow. Of course it will. Passing the data directly to the callback that bumps a counter is faster than allocating a new string, formatting the data, and then passing it to the callback that bumps a counter. It may not look like much, but avoiding unnecessary GC allocations means the GC will have less work to do later when a collection is run, thus you save time over the long term. > To run the slow test manually use the `words_quarter.txt` dictionary > (the phone numbers file doesn't matter much - it's all in the > dictionary). > > But pls run the benchmarks yourself as I am not going to keep running > it for you, and would be nice if you posted your solution on a Gist > for example, pasting lots of code in the forum makes it difficult to > follow. I'll push the code to github. T -- "No, John. I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev
Re: Understanding the Use of Nested Import and Selective Import in D
On Wednesday, 17 January 2024 at 13:38:10 UTC, Orfeo wrote: On Tuesday, 16 January 2024 at 19:05:43 UTC, Jonathan M Davis wrote: When local imports were introduced, they were pushed as best practice (in part, because Andrei is a big fan of them), and I think that for the most part, they still are, but there's definitely going to be some disagreement on it. [...] thanks a bunch for your in-depth analysis. Your insights have been helpful in clarifying my understanding of how to approach `import` in my code. I've come to prefer function/struct-level imports where possible... with the exception being those imports which get used by a lot of functions within the same module... because they just become tiringly repetitive, there's a point where it simply becomes cleaner to have a single import at the top of the file instead of the same imports again and again within function scope (though there's never going to be a "threshold" everyone agrees on, I think everyone has one). My main reasoning is that D tools, surprisingly, cannot do "Optimize Imports" (turns out that with all the metaprogramming going on , it's impossible to tell for sure which imports are being used - or so I read in another thread about this topic)... so you're likely to get lots of unused imports over time as you change your code, which I just find distatestful - and it become harder and harder to keep the imports "correct". Keeping imports more local makes that a little bit easier to avoid, besides the other reasons like making it easier to refactor. Regarding selective imports: those are helpful to people reading your code, because they may not be as familiar with all the names exported by the modules you're using. The argument against that from the "D selective imports have effects you may not want" seem highly unconvincing to me because it's basically talking about ugly edge cases related to how UFCS works which maybe should even be fixed and not exist at all?! Avoiding selective imports because of that is the proverbial throwing the baby out with the bath water.
Re: Understanding the Use of Nested Import and Selective Import in D
On Tuesday, 16 January 2024 at 19:05:43 UTC, Jonathan M Davis wrote: When local imports were introduced, they were pushed as best practice (in part, because Andrei is a big fan of them), and I think that for the most part, they still are, but there's definitely going to be some disagreement on it. [...] thanks a bunch for your in-depth analysis. Your insights have been helpful in clarifying my understanding of how to approach `import` in my code.
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wednesday, 17 January 2024 at 11:56:19 UTC, evilrat wrote: On Wednesday, 17 January 2024 at 11:20:14 UTC, Renato wrote: That means the input file is still not ASCII (or UTF-8) as it should. Java is reading files with the ASCII encoding so it should've worked fine. It seems that it is only works with ASCII encoding though. Yes, that's according to the rules - only ASCII for everything.
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wednesday, 17 January 2024 at 11:20:14 UTC, Renato wrote: That means the input file is still not ASCII (or UTF-8) as it should. Java is reading files with the ASCII encoding so it should've worked fine. It seems that it is only works with ASCII encoding though.
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wednesday, 17 January 2024 at 10:50:26 UTC, evilrat wrote: On Wednesday, 17 January 2024 at 10:43:22 UTC, Renato wrote: On Wednesday, 17 January 2024 at 10:24:31 UTC, Renato wrote: It's not Java writing the file, it's the bash script [`benchmark.sh`](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/master/benchmark.sh#L31): ``` java -cp "build/util" util.GeneratePhoneNumbers 1000 > phones_1000.txt ``` Perhaps using this option when running Java will help: ``` java -DFile.Encoding=UTF-8 ... ``` I've used powershell env var to set output to utf8, D version now works but java doesn't. ``` java -Xms20M -Xmx100M -cp build/java Main print words-quarter.txt phones_1000.txt Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 65485 out of bounds for length 10 at Trie.completeSolution(Main.java:216) at Trie.forEachSolution(Main.java:192) at PhoneNumberEncoder.encode(Main.java:132) at Main.lambda$main$1(Main.java:38) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) at Main.main(Main.java:38) ``` This is this line: ``` var digit = chars[ index ] - 48; ``` That means the input file is still not ASCII (or UTF-8) as it should. Java is reading files with the ASCII encoding so it should've worked fine.
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wednesday, 17 January 2024 at 10:43:22 UTC, Renato wrote: On Wednesday, 17 January 2024 at 10:24:31 UTC, Renato wrote: It's not Java writing the file, it's the bash script [`benchmark.sh`](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/master/benchmark.sh#L31): ``` java -cp "build/util" util.GeneratePhoneNumbers 1000 > phones_1000.txt ``` Perhaps using this option when running Java will help: ``` java -DFile.Encoding=UTF-8 ... ``` I've used powershell env var to set output to utf8, D version now works but java doesn't. ``` java -Xms20M -Xmx100M -cp build/java Main print words-quarter.txt phones_1000.txt Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 65485 out of bounds for length 10 at Trie.completeSolution(Main.java:216) at Trie.forEachSolution(Main.java:192) at PhoneNumberEncoder.encode(Main.java:132) at Main.lambda$main$1(Main.java:38) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) at Main.main(Main.java:38) ```
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wednesday, 17 January 2024 at 10:24:31 UTC, Renato wrote: It's not Java writing the file, it's the bash script [`benchmark.sh`](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/master/benchmark.sh#L31): ``` java -cp "build/util" util.GeneratePhoneNumbers 1000 > phones_1000.txt ``` Perhaps using this option when running Java will help: ``` java -DFile.Encoding=UTF-8 ... ```
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wednesday, 17 January 2024 at 09:15:02 UTC, evilrat wrote: On Wednesday, 17 January 2024 at 07:11:02 UTC, Renato wrote: If you want to check your performance, you know you can run the `./benchmark.sh` yourself? Out of curiosity I've tried to manually run this on Windows and it seems that Java generator for these numbers files is "broken", the resulting count or print runs fine for both Java and D versions provided in your D branch, but fails with generated files. D version complains about bad utf8 encoding. I've opened the generated file in text editor and it is UTF-16 (little-endian with BOM). Tried with adoptium jdk 17 and 21 (former openjdk), but I guess it doesn't matter since UTF-16 is default on Windows. It's not Java writing the file, it's the bash script [`benchmark.sh`](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/master/benchmark.sh#L31): ``` java -cp "build/util" util.GeneratePhoneNumbers 1000 > phones_1000.txt ``` Java is just printing to stdout. I wasn't aware that piping like this would use the OS default encoding. Unfortunately I don't have Windows here, but try to change the encoding used by the bash script maybe?
Re: Would you recommend TDPL today?
On Tuesday, 16 January 2024 at 02:25:32 UTC, matheus wrote: Hi, I'm mostly a lurker in these Forums but sometimes I post here and there, my first language was C and I still use today together with my own library (A Helper) which is like a poor version of STB (https://github.com/nothings/stb). [...] I suggest also Ali book, Programming in D, is excellent [1] [1] http://ddili.org/ders/d.en/index.html
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wednesday, 17 January 2024 at 07:06:25 UTC, Renato wrote:
On Tuesday, 16 January 2024 at 22:15:04 UTC, Siarhei Siamashka
wrote:
On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
It's a GC allocations fest. Things like this make it slow:
```diff
{
-string digit = [digits[0]];
+string digit = digits[0 .. 1];
words.insertBack(digit);
```
I was under the impression that `[digits[0]]` would just use a
stack allocation??
The profiler does not show any GC anymore, are you sure it's a
"GC allocations fest"???
nah, you are allocating new array out of single digit while the
latter is just takes a slice.
there is 'scope' storage specifier for when you know your
variable won't escape the scope to place it on stack (works for
classes too), but I'm not sure if it will work with array.
`scope string digit = [digits[0]];`
Re: Help optimize D solution to phone encoding problem: extremely slow performace.
On Wednesday, 17 January 2024 at 07:11:02 UTC, Renato wrote: If you want to check your performance, you know you can run the `./benchmark.sh` yourself? Out of curiosity I've tried to manually run this on Windows and it seems that Java generator for these numbers files is "broken", the resulting count or print runs fine for both Java and D versions provided in your D branch, but fails with generated files. D version complains about bad utf8 encoding. I've opened the generated file in text editor and it is UTF-16 (little-endian with BOM). Tried with adoptium jdk 17 and 21 (former openjdk), but I guess it doesn't matter since UTF-16 is default on Windows.
Re: Nested delegates and closure allocations
On Tuesday, 16 January 2024 at 17:21:12 UTC, FeepingCreature wrote: Correct. [...] Thanks, I think I understand.
