i understand why you don't do an audit :D

[babut]

if i encrypting an empty partition, then the speed is 20mb\s(if i format the partition directly to DC, then i can get a little more- 40mb\s. this has no logical explanation), but if i close the page with the encryption progress, and after a while open it again, i can see a speed close to theoretically possible, which immediately drops to 20/40mb\s. but, since the progress over the past time corresponds to a speed of 20/40mb\s, then this displayed high speed is either a counting error or intentional misleading.
this is only when encrypting empty partitions. in real work, the speed is slightly higher, but still four times slower than theoretically possible. surprisingly, when working in multithreading(when several files are read from the disk at the same time), the total speed of all threads is quite high, but in practice no one needs it.
probably all my samsung and toshiba disks are not good enough(just "suxxx") for your program(but they are suitable for other programs that are not as "fast" as your %D)

 

[DavidXanatos]

It's an accounting error and not worth fixing.
What I always do is I create a partition with windows disk management, then I shrink it to as close to 0 as possible, encrypt it with DC and then once that is done in the Windows disk management I expand it to the full size.

The only security impact this has is that an attacker can tell how much of a partition is filled with data and what is empty,
something that on a SSD with TRIM enabled, he also can do, no mater how the partition was created.

 

[megaslowpoke]

I create a partition with windows disk management, then I shrink it to as close to 0 as possible, encrypt it with DC and then once that is done in the Windows disk management I expand it to the full size

by the way, with such use on some new SSDs the partition gets corrupted when expanding back, and where the data is corrupted you can see a repeating pattern BBBB0000h, I still can't find the time to check everything and write in issues