Agree but mentioned the disk as that is an easy target for investigation and possible "quick fix/adjustment". But yes, it seems the DLL is where all the processing and CPU usage is occurring. Harsh should explain more fully the input and output file types and perhaps the purpose of the conversion in order to get possible alternative solutions.



>Re disk: I thought I ran into an issue once with having too many files in a folder, that *might* be an issue for Harsh if he's processing many files. Found a couple of interesting threads on StackOverflow:
>
>http://stackoverflow.com/questions/197162/ntfs-performance-and-large-volumes-of-files-and-directories
>http://stackoverflow.com/questions/2994544/how-many-files-in-a-directory-is-too-many-on-windows-and-linux
>
>Still, from the numbers he gave earlier it looks like his process is CPU-bound. Improving disk might help a bit but it seems unlikely to yield large gains in overall performance.
>
>If I were in that position I'd take a hard look at the DLL. Unless it's designed for and proven to be high-performance, there may be better options.
>
>>Hello Harsh,
>>
>>Also check Windows Device Manager and look at the properties dialog of the hard disk. Look under the Policies tab. Is "Enable write caching" switched on? If not, try turning it on and see the performance.
>>
>>Ultimately you are depending on (1) a 3rd party conversion DLL, (2) your CPU, (3) your disk drive. Number 3 you have options such as write cache, faster disk, or solid state disk. Number 2 you have less options because the CPU is already very good. Number 1 you have no control over other than looking for another product. Therefore, I would first look at the disk system.
>>
>>If this is really a mission critical project you can split the work over several computers, sending the files to each computer and they producing the output files.