"Regan Heath" <regan@netwin.co.nz> wrote in message news:ops4v0euuc23k2f5@nrage.netwin.co.nz...
>I have a simple question, for Matthew largely.
>
> Lets assume the latest version of recls is packaged with the latest version of the D compiler.
>
> I download the latest D compiler, extract all the files and am at the stage where I can write a D program and compile with "dmd <file>" at command prompt.
>
> I want to write a program which uses recls, what further steps do I have to take in order to do so?
>

AFAIK there are no a priori reasons why std.recls would not be as seamlessly integrated as std.zlib. IIRC, that was exactly how it started out.

I can't recall why the stagnation meant it stopped being like that. I do recall some issues with STLport, but they were solved. (They probably haven't been folded in to what's in Phobos, of course.)

One thing: I implemented a special part of it for D which does a kind of "delay-load" thing with WININET.DLL, so no user is required to actually link to anything other than the standard DMD libs in order to use the recursive FTP searching functionality. (<playful>... can listdir search FTP sites ... </playful>)

> I ask because I just tried to use the one which is currently part of the D compiler distribution and failed to get anything working, missing symbols. I suspect I need to build a recls library. I found some makefiles but I failed to get those to compile even after modifying them to find the DMC tools dmc, lib, link, etc as opposed to the microsoft ones I have install with VC6.0. FYI the error reported a duplicate symbol in my Microsoft headers. I wonder if it is including the wrong files or if I have old files.
>
> Either way, that is not the point of this post, rather, I simply want to know what a user has to do in an ideal situation in order to use the latest recls with D. I suspect the C library is a requirement that is not going to vanish in the future?

Do you mean the latest that is in Phobos, or the real latest version of recls (1.7.2 from http://recls.org/)?

> If so, I would prefer not to have that requirement. In other words I would prefer the solution to be a native D/phobos one that does not rely on external libraries.

Well, since it's still std.recls, I think that's a pretty reasonable requirement. ;-)

> I am not making an argument _for_ "listdir" in it's current form. I am making an argument for a solution that does not use an external library, unless (there is always one of these) that solution has a clear advantage that the "non-external lib" solution cannot match.
>
> Of course if I am wrong about the external library requirement, lemme know and we'll ignore this point :)

IMO. It depends. There are arguments both for and against the external C library approach. Obviously, these include a balance between the inconvenience to the producer(s) of D against the advantage of having the library. There're also ancillary reasons. For example, the Open-RJ library has advanced beyond the capabilities of std.openrj. Since std.openrj is pure D, integrating the new capabilities is a lot more effort than will be the case with updating std.recls, which is pretty much a no-brainer.

HTH

Matthew

>
> Regan
>
> On Mon, 13 Feb 2006 11:55:41 +1100, Matthew <nowhere@noaddress.co.us> wrote:
>> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:dsokf0$3d$1@digitaldaemon.com...
>>> Forgive me, but from reading the samples in this argument, I see:
>>>
>>> Matthew says the standard library should do as much of the task as conceivably possible, within reasonable bounds.  He says D's Phobos does not do this.
>>
>> I don't think that's an accurate representation of my position. In many cases I like a minimalist approach.
>>
>> The point here is that the underlying operations are I/O bound, so any decent library needs to minimise the amount of I/O. (And avoid non-linear user-mode behaviour as well, of course.)
>>
>>> Walter says that the standard library should be simple, and support
>>> normal
>>> options with the option of adding code on the user-side for complex
>>> tasks.
>>
>> Great. In which case listdir() shouldn't be recursive. There's a good
>> reason
>> why no operating systems provide such recursive facilities, as the
>> designer(s) of listdir() have failed to recognise. (Note: UNIX does have
>> glob(), which is effectively what listdir() is trying to be, and that has
>> the same caveats, but that's not a system call, and it's got a different,
>> and generally more limited, kind of recursion.)
>>
>>> Anyway, if I were to take a very large array, and run through it 8
>>> times -
>>> ach time pulling out just 1/16th of the array (half of what I want), I
>>> would clearly be a moron.  If, on the other hand, I went through it once
>>> and pulled out the 8/16ths (half) of the array all in one blow, it would
>>> seem I regained my senses.
>>>
>>> This is not rocket science, and I fail to see why it was necessary to develop a testcase to show this.  Or why anyone might be surprised that doing it the better way would take a small fraction of the time. Obviously, really.
>>
>> True, but there's another flaw in the design. By combining recursion and
>> en
>> bloc results it can lead to huge latencies and memory consumption,
>> suffering
>> from non-linear behaviour. (Perhaps I didn't stress that aspect enough
>> in my
>> previous rants. The two aspects are not commensurate, and if listdir() is
>> preserved then it needs to stop being recursive.)
>>
>>> But, yes, the question is in the implementation.  And from my
>>> description
>>> above, if it is so correct... this is more of a philosophical question
>>> than one about performance.
>>
>> Well, the question is in the design. If that tallies with your point,
>> then
>> ok. If not, then I disagree.
>>
>>> This just seems like an awful amount of commotion for the relatively
>>> uncommon task of building a full-tree list of all files matching some
>>> extensions.  I can count the number of programs I'd consider useful that
>>> do that on one hand (and grep, which does not do this, is the first
>>> one.)
>>> What a great measure of a library's design!
>>
>> It's horses for courses, surely? I do such things many many times a day.
>> You
>> do it rarely. Both are valid. A standard library needs general
>> facilities,
>> and all of those facilities should be well designed and implemented.
>>
>> My point is that this case is but one example of bad design in the Phobos
>> libraries. Yet Walter will refuse to acknowledge this until our bones are
>> dry and dusty. And there's a library already in Phobos that does such
>> things
>> well. Yet Walter refuses to update it.
>>
>> I cannot fathom either. To me, the three words "I am wrong" are perhaps
>> the
>> three most useful in the lexicon. So very liberating. So engendering of
>> mutual respect, since if you admit your flaws to me, I can admit mine to
>> you, and we each have much smaller and more manageable facades to
>> project.
>>
>> Broadly, I want to know why Phobos appears little more than a fetid
>> stagnant
>> heap. Nobody likes it. I'm sure contributors would like to be able to
>> revise/remove/rework their contributions. (apart from std.recls, I'd
>> like to
>> junk / rewrite all mine.) But Walter neither appears to do much about it,
>> nor will he cede its control to people who might be more expert in
>> library
>> design and/or have more time to work on it. (I am not meaning me, here,
>> in
>> case anyone thinks this is a sideways auto-backslap.)
>>
>>>
>>> I wonder which better supports VESA.  That used to be big, didn't it?
>>
>> No idea. It impacts not one whit on my programming life.
>>
>>
> 

"Derek Parnell" <derek@psych.ward> wrote in message news:1f861fnt3wbv4.2uxo6i97eesd$.dlg@40tude.net...
>

Beep! Next, please. <g>

> Now settle down, kiddies. You're only getting yourself all upset.
>
> All we have gained from this unsightly tantrum is that listdir is not optimised and recls is optimised.


Get your hand off it, Derek. I know you're not an idiot, so why affect this patronising and disingenuous position?

> I have a gut feeling that optimising listdir is not going to be all that hard to do. I even had a 10-minute go at doing that and got a huge performance improvement.

Gotta love those gut feelings.

Sorry mate, but you're again returning en bloc from a recursive
function. Perhaps you weren't paying attention. (Easy to ignore,
these kiddies, eh?) Big delays. Non-linear behaviour.
Going to have to run that one through the night as well. ;-)

Basically, to get a sensibly recursive library, the basic design of recls will have to be approximated. Given that, why not use std.recls?

This is not a rhetorical question, Walter. I want to know why. Please do me the courtesy of answering this question, perhaps in one of the stream of listdir()-tweaks posts I'm expecting to see over the next 24 hours or so. Then I can give up this point once and for all. Otherwise, I'm just going to keep asking until I get an answer.

"Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:dsod2v$2o1s$1@digitaldaemon.com...
> Conversely, D's syntax and apparent power means that listdir() is very
> succinct. In source size it's probably ~1% that of recls, if that.
> However,
> this succinctness is specious, misleading the author(s) of listdir() into
> a
> Bad Design. Simply put, if listdir() wants to be recursive, it cannot
> return
> en bloc. If it wants to return en bloc, it cannot be recursive. One can
> equivocate as much as one wishes, but that equation cannot be avoided.

I believe listdir() shows that it can be done both ways, and done well. There are two essential versions of listdir() - one visits each file and directory in the path, and passes the results *as they are found* to a delegate. The delegate, of course, can execute arbitrary user-supplied code to do anything desired at each point in the search.

The second listdir(), which I posted the listing for, calls the first listdir() with a delegate that assembles the results into one large array, in a way that is likely the most common way listdir() would be used. If what it does is not what is desired, it's a simple thing to provide a delegate to do *whatever* is desired, as I showed with the rewritten benchmark. All that did was replace the call to fnmatch with one to RegExp.test. (I could also extend fnmatch to accept '|', and the results would be the same without expanding the code size by 100x, but I wanted to show how this could be done by the user without changing library code.)

Does this flexibility, which can be achieved without modification of any library code, mean that listdir() is a Bad Design? I disagree. I tend to believe in the "building block" idea of library design, that rather than build one large function with a lot of options, that one builds smaller functions that can be assembled together as needed. In listdir()'s case, it's the ability of it to call user-supplied code via the delegate that lends itself to this approach. Instead of relying on flags passed to one do-it-all function, the decision on what to do with each entry is determined by user-supplied code.

You commented in another post that the way listdir() appends filenames to an array is also a bad design. I'll reply that, ideally, the array would be preallocated based on the number of entries that will be put into it, and then simply filled in. Unfortunately, there is *no way* to even guess how big the array will be unless 2 passes are made over the disk. As you correctly pointed out, however, this will be unacceptably slow (and also buggy, as the disk contents can change between passes). A very reasonable way is to assemble the array as the pieces come in. Under the hood, the array is resized in powers of 2, so there aren't that many alloc/copy operations going on. I think the results speak for themselves - it's plenty fast enough.

So now I'll comment a bit on recls (this is based on the recls shipping with D now, your later versions might correct any or all of these problems).

First the good stuff:

1) It works (never underestimate this feature!)

2) It's fast

3) It's a fine example of how to adapt a C++ library to be accessible from D (and other languages)

4) It uses unittests and contract programming (double plus good!)

Now the not as good stuff, most of which I've emailed to you in one form or another:

1) It's gigantic. Something is just not right when something that should be simple, a recursive directory lister, winds up being 250K of source. Subsequent recls versions got much larger than that. Even the adapter code std/recls.d is far larger than the entire D code to support listdir().

2) It's written (necessarilly, because it's in C++) in the C++ style of doing things. C++ style code adapts rather poorly to D. A D standard library component should be written in the D style of doing things.

3) The D style, for example, makes use of delegates, because it adds a lot of flexibility with essentially no overhead. Doing delegates in C++ is horrible, so what people do instead is write do-it-all high level functions that accept lots of flags adjusting the behavior. The designer tries to anticipate every way the function might be used, and adds flags and arguments for each. Even if the behavior of some of the options is rarely needed, the bloat to implement it gets added on to every user of the function. Consider, for example, if one needs recls to skip directories named "fred". The choices are all unattractive - petition the standards committee to add the feature, fork the library source, or build one's own from the ground up. With delegates, just write a simple delegate filter, and the library is unmodified.

Modern C++ has tried to deal with this problem by using templates, with technical success, but acceptance by the general C++ community of this technique has been poor due to its complexity. Even if they were accepted, templates just ain't going to cross language boundaries.

4) recls, by its nature of being self-contained, duplicates functionality found in other D standard library packages (like std.path). Standard library components should be orthogonal, not redundant.

5) recls, because it's in C++, can't deal with UTF.

6) It makes sense to put a D shell around C++ code when there is no other reasonable way to proceed (wxD is an example of that). But this isn't the case with recls - it's designed to be C++ code callable from other languages. That makes sense as a demonstration project, but it doesn't make sense as a standard language component, when just the work writing the D wrapper exceeds the work to do a 100% D implementation.

I won't argue that I'm a great library designer, or that every module I wrote in Phobos is the cat's meow. Far from it. I'll just leave it at listdir() being a pretty good design.

Well, the best approach would be, I think, to call a callback on every match, but this is contrary to common usage.  That said, in any case where I expect large sets of data I either use a callback or stateful (I do realize that's not a word) method of retrieving the data.

This also is not rocket science, although it is contrary to how most programmers think and are taught.

Of course, it does appear to me that listdir supports callbacks, and this doesn't appear to complicate user-code too much (although it isn't quite as simple as a foreach.)  Still, that only seems like a trivial design-choice difference to me.

I don't know much about recls, but if it's just a class that provides incremental searching (e.g. like you might with a callback to listdir.) I'd imagine it can't be too long or complicated.

-[Unknown]


> True, but there's another flaw in the design. By combining recursion and en bloc results it can lead to huge latencies and memory consumption, suffering from non-linear behaviour. (Perhaps I didn't stress that aspect enough in my previous rants. The two aspects are not commensurate, and if listdir() is preserved then it needs to stop being recursive.)

Since nothing else in Phobos can do anything with them, I should hope not.  The last thing I would want is a lopsided library.

Of course, I have the opinion that basic FTP support should, indeed, be in the library, along-side some basic HTTP support, but it doesn't seem like that's an opinion enjoyed by many other than me.

-[Unknown]


> (<playful>... can listdir search FTP sites ... </playful>)

Matthew wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message news:1f861fnt3wbv4.2uxo6i97eesd$.dlg@40tude.net...
> 
> Beep! Next, please. <g>
> 
>> Now settle down, kiddies. You're only getting yourself all upset.
>>
>> All we have gained from this unsightly tantrum is that listdir is not optimised and recls is optimised.
> 
> 
> Get your hand off it, Derek. I know you're not an idiot, so why affect this patronising and disingenuous position?

I think a less temperamental discussion would benefit everyone nonetheless.


Given this capability:

> I believe listdir() shows that it can be done both ways, and done well. There are two essential versions of listdir() - one visits each file and directory in the path, and passes the results *as they are found* to a delegate. The delegate, of course, can execute arbitrary user-supplied code to do anything desired at each point in the search.

what's wrong with using listdir(). I am not trying to instigate, I
really just want to know.

"Matthew" <nowhere@noaddress.co.us> wrote in message news:dsoiul$305p$1@digitaldaemon.com...
> Where does this 6 come from? (Ignoring the first times for each to give a fair comparison) the D version takes 31 times longer than the Ruby version!
>
>      80359 2540203
>      83656 2733218
>      88062 2630031
>      86809 2864390
>
>      84721.5 2691961 31.77423

I was looking at user time:

From your post:
--------------------
D:      time: elapsed: 7,484ms, kernel: 3,593ms, user: 3140ms
Ruby: time: elapsed: 3,781ms, kernel: 3,031ms, user: 500ms
D:      time: elapsed: 8,906ms, kernel: 3,187ms, user: 3,671ms
Ruby: time: elapsed: 3,687ms, kernel: 2,734ms, user: 703ms
D:      time: elapsed: 8,953ms, kernel: 3,640ms, user: 3296ms
Ruby: time: elapsed: 3,718ms, kernel: 2,890ms, user: 593ms
D:      time: elapsed: 7,500ms, kernel: 4,093ms, user: 2,734ms
Ruby: time: elapsed: 3,750ms, kernel: 3,031ms, user: 531ms
D:      time: elapsed: 8,828ms, kernel: 3,906ms, user: 2,937ms
Ruby: time: elapsed: 3,687ms, kernel: 3,093ms, user: 390ms
-------------------- 

"Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:dsoi09$2v9i$1@digitaldaemon.com...
> But questions abound: How many matching files are under c:\cbx?

It's 8107 results, about 800 Mb.

> What is 2.67? What is 0.36?

Seconds.

> How were these times taken?

Using the timer.exe program I use for all program timings.

>Why have you changed the number of patterns?

I don't have java, vbs, etc., files, so I modified it so it would find files that actually were there.

> Hey, why not just use 1?

Because the issue was how many sweeps over the filesystem. It's pretty obvious, by both your results and mine, that that's the determinant of the time.

> What do you think you've proved/demonstrated by a test of some D against
> some other D?
> Why haven't you installed Ruby and done a comparison?

Because if:
    A = 6 * B
    B = 3 * C
therefore, I don't need to compare A with C to deduce that:
    A = 18 * C

Of course, there will be other differences since your hard disk setup is different than mine, but the ratios should hold.

> Where is the comparison of the memory hit?

I didn't do one. I don't think it would provide that useful of information, because one can get wildly different results depending on how the garbage collector is tuned.

> Why offer conjecture ("perhaps twice as fast as the Ruby one") when I spent a lot of time and effort producing cold hard facts?

Because I don't have Ruby on my system. But you can compile/run the example I gave you, modifying it back to reflect your directory structure, in a couple minutes. Why not give it a try?

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dsonub$5l1$1@digitaldaemon.com...
>
> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:dsod2v$2o1s$1@digitaldaemon.com...
>> Conversely, D's syntax and apparent power means that listdir() is very
>> succinct. In source size it's probably ~1% that of recls, if that.
>> However,
>> this succinctness is specious, misleading the author(s) of listdir() into
>> a
>> Bad Design. Simply put, if listdir() wants to be recursive, it cannot
>> return
>> en bloc. If it wants to return en bloc, it cannot be recursive. One can
>> equivocate as much as one wishes, but that equation cannot be avoided.
>
> I believe listdir() shows that it can be done both ways, and done well. There are two essential versions of listdir() - one visits each file and directory in the path, and passes the results *as they are found* to a delegate. The delegate, of course, can execute arbitrary user-supplied code to do anything desired at each point in the search.
>
> The second listdir(), which I posted the listing for, calls the first listdir() with a delegate that assembles the results into one large array, in a way that is likely the most common way listdir() would be used. If what it does is not what is desired, it's a simple thing to provide a delegate to do *whatever* is desired, as I showed with the rewritten benchmark. All that did was replace the call to fnmatch with one to RegExp.test. (I could also extend fnmatch to accept '|', and the results would be the same without expanding the code size by 100x, but I wanted to show how this could be done by the user without changing library code.)
>
> Does this flexibility, which can be achieved without modification of any library code, mean that listdir() is a Bad Design? I disagree. I tend to believe in the "building block" idea of library design, that rather than build one large function with a lot of options, that one builds smaller functions that can be assembled together as needed. In listdir()'s case, it's the ability of it to call user-supplied code via the delegate that lends itself to this approach. Instead of relying on flags passed to one do-it-all function, the decision on what to do with each entry is determined by user-supplied code.
>
> You commented in another post that the way listdir() appends filenames to an array is also a bad design. I'll reply that, ideally, the array would be preallocated based on the number of entries that will be put into it, and then simply filled in. Unfortunately, there is *no way* to even guess how big the array will be unless 2 passes are made over the disk. As you correctly pointed out, however, this will be unacceptably slow (and also buggy, as the disk contents can change between passes). A very reasonable way is to assemble the array as the pieces come in. Under the hood, the array is resized in powers of 2, so there aren't that many alloc/copy operations going on. I think the results speak for themselves - it's plenty fast enough.

This is total crap. You were the one that demonstrated the usage. Now somehow you're telling us that in order to be able to use listdir() in a non-pathalogical way one must not only be cognisant of the leaks in its abstraction but also be knowledgeable to, say, the level of someone who's expert in writing their own recursive search libraries. It's just rubbish. The library is bad, and that's plain because I used it in a bad way following your code sample that was presented as a rejoinder to a criticism of D's current inadequacies at recursive file processing. If you can't see the problem there, I really do shudder.

>
> So now I'll comment a bit on recls (this is based on the recls shipping with D now, your later versions might correct any or all of these problems).
>
> First the good stuff:
>
> 1) It works (never underestimate this feature!)
>
> 2) It's fast
>
> 3) It's a fine example of how to adapt a C++ library to be accessible from D (and other languages)
>
> 4) It uses unittests and contract programming (double plus good!)
>
> Now the not as good stuff, most of which I've emailed to you in one form or another:
>
> 1) It's gigantic. Something is just not right when something that should be simple, a recursive directory lister, winds up being 250K of source. Subsequent recls versions got much larger than that.

Three things:
 - and yet you agreed to take 1.6, assuming it shrank
 - I put in a lot of work to shrink it.
 - why do you focus on source size, not code size? As I said, with VC7.1
it's ~20KB, and many other compilers are around the same.

> Even the adapter code std/recls.d is far larger than the entire D code to support listdir().

This is a complete furphy.

First, you're hardly comparing like with like. Does listdir() handle reparse points, ~ (home), follow/not-follow links, provide a full suite of entry attributes (incl. Drive, Directory, File, FileName, FileExt, ShortFile, OS-independent directory (i.e. incl drive on Win), SearchDirectoryRelativePath, times, size, attributes, a collection of directory parts, etc.) and so on and on.

Second, since I've not been afforded the facility for changing this in 2.5 years, how can it possibly be judged as representative of an inate characteristic of the library. This is some medieval reasoning you've got going.

> 2) It's written (necessarilly, because it's in C++) in the C++ style of doing things. C++ style code adapts rather poorly to D. A D standard library component should be written in the D style of doing things.

This contradicts point 3) above. And it's quite wrong.

> 3) The D style, for example, makes use of delegates, because it adds a lot of flexibility with essentially no overhead. Doing delegates in C++ is horrible, so what people do instead is write do-it-all high level functions that accept lots of flags adjusting the behavior. The designer tries to anticipate every way the function might be used, and adds flags and arguments for each. Even if the behavior of some of the options is rarely needed, the bloat to implement it gets added on to every user of the function. Consider, for example, if one needs recls to skip directories named "fred". The choices are all unattractive - petition the standards committee to add the feature, fork the library source, or build one's own from the ground up. With delegates, just write a simple delegate filter, and the library is unmodified.

"Kick 'im in. If he sinks he's innocent, if he floats we'll hang 'im!"

How am I supposed to keep up with the D way of doing things when I cannot update the code for 2.5 years.

> Modern C++ has tried to deal with this problem by using templates, with technical success, but acceptance by the general C++ community of this technique has been poor due to its complexity. Even if they were accepted, templates just ain't going to cross language boundaries.

Completely irrelevant.

How come I've been able to adapt recls to delegates in .NET then, eh?

> 4) recls, by its nature of being self-contained, duplicates functionality found in other D standard library packages (like std.path). Standard library components should be orthogonal, not redundant.

Arguable. I'm pretty sure that a fair amount of the duplication was added into std.path _after_ std.recls first entered Phobos. Cuckoo, cuckoo

> 5) recls, because it's in C++, can't deal with UTF.

Furphy.

This was raised and addressed. A couple of years ago. (Though may be true in phobos version.)

> 6) It makes sense to put a D shell around C++ code when there is no other reasonable way to proceed (wxD is an example of that). But this isn't the case with recls - it's designed to be C++ code callable from other languages. That makes sense as a demonstration project, but it doesn't make sense as a standard language component, when just the work writing the D wrapper exceeds the work to do a 100% D implementation.

Is this the closest I'm going to get to a straight answer?

You're wrong, since listdir is most certainly bad design, but since you don't agree, may I interpret the above to mean "recls is not sufficiently good/feature-unique to be a non-100% D library, and therefore is not acceptable in Phobos"?

I presume this also means that you're no longer interested in recls2. As well as the file-system and (WIndows only) FTP recursive enumerations (for which there's no Phobos "ftp_listdir()", AFAIK), will you be adding in recursive searching of the registry, XML docs, LDAP, etc. etc. etc. ? If so, great. I look forward to using them. If not, why the reversal now of another agreement that we made a year or so ago?

Or maybe you're keeping a crippled recls(1) in now to motivate me to do recls2? If so, great. I'm very motivated.

> I won't argue that I'm a great library designer, or that every module I wrote in Phobos is the cat's meow. Far from it. I'll just leave it at listdir() being a pretty good design.

It's not. It's a pretty bad design. But all the rationale for that opinion are in previous posts, so I'll save my breath.

But if you acknowledge problems with the library, and I'm offering to help you fix one of them, why knock it back? I'd far rather you just remove std.recls than leave it in its crippled state.


Well, that's me done. I guess I've had the closest I'm going to get to a straight, if erroneously reasoned, answer. Thanks. Please remove std.recls at the next release cycle, and we can all take a load off.

You see, I told you if you tried hard enough you'd convince yourself you're right! <g>

Matthew

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dsopmo$7ce$1@digitaldaemon.com...
>
> "Matthew" <nowhere@noaddress.co.us> wrote in message news:dsoiul$305p$1@digitaldaemon.com...
>> Where does this 6 come from? (Ignoring the first times for each to give a fair comparison) the D version takes 31 times longer than the Ruby version!
>>
>>      80359 2540203
>>      83656 2733218
>>      88062 2630031
>>      86809 2864390
>>
>>      84721.5 2691961 31.77423
>
> I was looking at user time:
>
> From your post:
> --------------------
> D:      time: elapsed: 7,484ms, kernel: 3,593ms, user: 3140ms
> Ruby: time: elapsed: 3,781ms, kernel: 3,031ms, user: 500ms
> D:      time: elapsed: 8,906ms, kernel: 3,187ms, user: 3,671ms
> Ruby: time: elapsed: 3,687ms, kernel: 2,734ms, user: 703ms
> D:      time: elapsed: 8,953ms, kernel: 3,640ms, user: 3296ms
> Ruby: time: elapsed: 3,718ms, kernel: 2,890ms, user: 593ms
> D:      time: elapsed: 7,500ms, kernel: 4,093ms, user: 2,734ms
> Ruby: time: elapsed: 3,750ms, kernel: 3,031ms, user: 531ms
> D:      time: elapsed: 8,828ms, kernel: 3,906ms, user: 2,937ms
> Ruby: time: elapsed: 3,687ms, kernel: 3,093ms, user: 390ms
> -------------------- 

So you used the less unfavourable test. Understandable.