Table 5.1 in this article, and some surrounding description,
indicate that ntfs converts to upper case when doing directory
inserts, so if you want to optimize the disk order for the order
processed by directory entry it seems toUpper would be a better
choice.
http://members.fortunecity.com/c
On Sunday, 22 April 2012 at 09:33:59 UTC, Marco Leise wrote:
So when you did your first measurements, with 160 seconds for
rmd, did you wait for the I/O to complete? Sorry if that's a
stupid question :p but that's the obvious difference when using
write-through from what the documentation says.
Am Sun, 22 Apr 2012 01:10:18 +0200
schrieb "Jay Norwood" :
> I was able to achieve similar efficiency to the defrag result on
> ntfs by using a modified version of std.file.write that uses
> FILE_FLAG_WRITE_THROUGH. The ntfs rmdir of the 2GB layout takes 6
> sec vs 161 sec when removing the unz
I was able to achieve similar efficiency to the defrag result on
ntfs by using a modified version of std.file.write that uses
FILE_FLAG_WRITE_THROUGH. The ntfs rmdir of the 2GB layout takes 6
sec vs 161 sec when removing the unzipped layout. I posted the
measurements in D.learn, as well as th
On Sunday, 8 April 2012 at 22:17:43 UTC, Somedude wrote:
Well, you can always do something like this:
version (parallel)
{
import std.parallelism;
// multithreaded
...
}
else
{
// single thread
...
}
Or rather:
// single thread zip
...
version (parallel)
{
import std.parallelis
Le 08/04/2012 18:14, Jay Norwood a écrit :
> On Sunday, 8 April 2012 at 09:21:43 UTC, Somedude wrote:
>> Hi,
>>
>> You seem to have done a pretty good job with your parallel unzip. Have
>> you tried a parallel zip as well ?
>> Do you think you could include this in std.zip when you're done ?
>
> I
Le 09/04/2012 00:15, Somedude a écrit :
> Le 08/04/2012 18:14, Jay Norwood a écrit :
>> On Sunday, 8 April 2012 at 09:21:43 UTC, Somedude wrote:
>>> Hi,
>>>
>>> You seem to have done a pretty good job with your parallel unzip. Have
>>> you tried a parallel zip as well ?
>>> Do you think you could i
On Sunday, 8 April 2012 at 16:14:05 UTC, Jay Norwood wrote:
There are signficant improvements also in copy operations as a
result of defrag by Name. 43 seconds vs 1 min 43 secs for xcopy
of sorted 2GB vs unsorted.
this is the 2GB folder defragged with sorted LCN by pathname
G:\>cmd /v:on /c
On Sunday, 8 April 2012 at 09:21:43 UTC, Somedude wrote:
Hi,
You seem to have done a pretty good job with your parallel
unzip. Have
you tried a parallel zip as well ?
Do you think you could include this in std.zip when you're done
?
I'm going to do a parallel zip as well. There is already
Le 08/04/2012 09:34, Jay Norwood a écrit :
> On Sunday, 8 April 2012 at 01:18:49 UTC, Jay Norwood wrote:
>> in it. Same 3.7 second delete. I'll have to analyze what is
>> happening, but this is a huge improvement. If it is just the
>> sequential LCN order of the operations, it may be that I ca
On Sunday, 8 April 2012 at 01:18:49 UTC, Jay Norwood wrote:
in it. Same 3.7 second delete. I'll have to analyze what is
happening, but this is a huge improvement. If it is just the
sequential LCN order of the operations, it may be that I can
just pre-sort the delete operations by the file
These are measured times to unzip and then delete a 2GB folder in
Win7. Both are using the parallel rmd to remove the directory on
a regular hard drive. The first measurement is for an unzip of
the archive. The second is remove of the folder when no defrag
has been done. The third is unzip o
12 matches
Mail list logo
