|
A friend of mine tried to write the fastest Win32 file copy a few years ago. He used 2 threads and 2 32K buffers (read one then switch and read other while writing the one ) and the Win32 API calls as opposed to the C Library file functions. I don't know if it was the best but it was 4 times faster than using the C library calls, mostly because they use small buffers, and 10 times faster than using Explorer on large files 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thank you very much.
I will have a try this way,soon.
|
|
|
|
|
If you're copying multiple files, you could spawn a thread for each file to copy so that, with respect to your program, the copying is taking place in parallel.
Judy
|
|
|
|
|
There's just one problem here. First and foremost, it depends on WHERE and TO you copy. The HD is far slower than the processor and memory, so the bottleneck is THERE.
Copying two files (or more) from the same HD and to the same HD, then it will slow down the operation at least 2x.
If the source and destination is different for each file, then yes, you can use threads. Otherwise you're just slowing down things.
|
|
|
|
|
Depends on how the program is written. If it is a series of CopyFile, CopyFile, CopyFile functions calls, I agree 100% with you. If however, the OP is doing things between each CopyFile call, this may speed his process up by _always_ having data at the HD level waiting to be written while the OPs other code is executing.
This is the kind of thing where you need to code it different ways and measure each ways performance in different source files / target disks scenarios. Sometimes you just have to say "sorry, hard drives are slow - you've just got to wait." That's why they made a wait cursor.
Judy
|
|
|
|
|
Ah, of course. You're absolutely right. One thread can take care of copying and one thread can take care of everything else that needs to be done meanwhile... But then again, you don't need to use synchronus file copy either... You can asynchronous. While the file is copying, the program can do other stuff like readying more data copy or something, as long as it doesn't read or write to the same HD, since that would slow things down.
|
|
|
|
|
In fact,the biggest problem is how to copy large file faster?
|
|
|
|
|
Hi,
I have taken a Dialog based Application. Upon some button Click I have some functionality to be done like creating a directory with Security attributes of a given user. Once I build this I got an Executable File which I Invoke from another Dialog based Application in Managed C++.
I invoked this executable (or process) by giving permmisions for an user say MyUser.
Process::Start(exepath,path ,username,strSecurePwd,domain);
So whatever is done in the executable file is being done by the MyUser.
Now, what I want is I have to Place all my functions in an
Executable File (or Seperate process) which should not have GUI.
Once I Invoke this Process all the functions in that should execute.
So, what sort of application I need to take for this to happen?
Any Suggestions or an approach to proceed would be helpful.
Thanks In Advance.
Today is a gift, that's why it is called the present.
|
|
|
|
|
You can use a normal application hiding the window. It has been talked about in some messages in this week. Take a look in forum
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
There is no requirement for a Win32 application to actually create a Window. I'd use the wizard to create an empty Win32 app and start from there with your own WinMain function. That's proper old school Windows programming 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Hello everyone,
Just interested to learn how C++ implements delete this statement internally. From logical point of view, I can not imagine how to implement a component which destroy itself.
What makes me confused is the component is relying on itself even in the process of destroy, how could it destroys itself from itself?
thanks in advance,
George
|
|
|
|
|
George_George wrote: ust interested to learn how C++ implements delete this statement internally.
Internally (simplified!), all functions of an object are global, and take a first, hidden, parameter this, which points to a memory-chunk holding the data-members of the object.
So, when calling the same member function on different instantiations of Object, you are executing the same code with a different this-pointer. Also, delete only frees the memory-chunk the this-pointer points to. It does nothing to the code of a class.
So, a code containing
delete this;
is very possible: delete calls the destructor (with the this-pointer) as usually and then frees the memory-chunk and returns control to the calling code. The object is destroyed like any normal object.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
|
Thanks jhwurmbach,
Your reply is very clear!
regards,
George
|
|
|
|
|
George_George wrote: how could it destroys itself from itself?
Not sure what you mean by that...
Nothing destroys itself "from" itself. Every call chain has its root in the system; every process and thread.
If the process or thread returns from its controlling function, the system will remove it from the scheduler and destroy it.
If you debug your application and have a look in the call stack, you'll see that the first stack frame is from the system.
Don't confuse the code loaded for the component and the object on the heap.
This question could be about COM. It doesn't have to be, but we can use it as an example.
When you call Release on an interface, the reference count is decreased and if it reaches zero the component "destroys itself", i.e. calls delete this and thus removes the object from the heap. When returning from the Release subroutine, the client continues executing. This means that the component is destroyed, but in a call chain that originates from the client. The code for the component would still be there, but the object on the heap is destroyed.
I hope this answers your question.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks Roger,
I think you mean delete this only destroys the data of instance, not the code itself. Right?
regards,
George
|
|
|
|
|
George_George wrote: I think you mean delete this only destroys the data of instance, not the code itself. Right?
Yes, that's one part of my reply.
The other part is meant to explain why an object doesn't "destroy" itself since I interpreted your question as if you worried about something like "what code will be executed after the object is destroyed". But I may have misunderstood you regarding that.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks Roger,
Now I can understand your points since from your help, I know the code and the data of instance are stored separately and destructor only frees the data, not the code.
have a good weekend,
George
|
|
|
|
|
Hello everyone,
From MSDN,
http://msdn2.microsoft.com/en-us/library/ms682583.aspx
parameter fdwReason of DllMain has four values,
DLL_PROCESS_ATTACH
DLL_PROCESS_DETACH
DLL_THREAD_ATTACH
DLL_THREAD_DETACH
I think we could simply understand what MSDN described about the four values in the following way after some experiment (I have read the big table and want to extract some brief and simple information to understand to remember),
DLL_PROCESS_ATTACH: will be called only once when the process loads the DLL for the 1st time
DLL_PROCESS_DETACH: will be called only once when the process unloads the DLL (when process stops)
DLL_THREAD_ATTACH: will be called every time when a thread inside the current process loads the DLL
DLL_THREAD_DETACH: will be called every time when a thread inside the current process unloads the DLL
Is that correct understanding?
thanks in advance,
George
|
|
|
|
|
yes .. ur understanding is correct
Ajay
|
|
|
|
|
Thanks Ajay,
I think the DllMain will be triggered when LoadLibrary (or FreeLibrary) is invoked in a process or a thread inside a process. Are there any other functions which will trigger DllMain other than LoadLibrary or FreeLibrary?
regards,
George
|
|
|
|
|
You're correct for processes but for threads the ATTACH and DETACH calls are made when the thread is started and completed not specifically when the Dll is loaded. In other words you don't load a Dll for each thread that uses it but you should generally load the Dll before any secondary threads that will share it are started.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
In your experience, when will DllMain be called with parameter value DLL_THREAD_ATTACH or DLL_THREAD_DETACH? Could you show a simple sample please?
regards,
George
|
|
|
|
|
|
Great article, thanks Nibu!
regards,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
