|
Mathieu Dijkstra wrote: c:\sevc6\comunication between variabel of 2 windows\ChildDialog.cpp(60) : error C2065: 'CComunicationbetweenvariabelof2windowsDlg' : undeclared identifier
Again, the compiler is telling you the problem. You have referenced an identifier that has not been declared. You need to include Comunicationbetweenvariabelof2windowsDlg.h at the top of ChildDialog.cpp.
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
cool that was the problem
many thanks 4 helping me wit my study on variabels and multy dialogs
problem is solved
i go studithis verry carful becorse i was having a problem whit this over 1 year
many thanks;)
waw you are a supper coder (by the way i had this problem also on a dutch formum but they dit not solve it) thanks agen
|
|
|
|
|
Hi there! I'm writting an app that deals a lot with files (both reading and writting) and that is slowing down my app.
What I need is a fast way to do the following operations on files:
- read
- writte
- append
- open
- close
I'm using c++ but inline assembly is an option.
Thx!
|
|
|
|
|
What APIs are you using for File I/O? Have you done any profiling to see where the bottlenecks are?
Since File I/O is extremly slow compared to memory I/O, I don't think you'll see much difference between C++ and assembly. Without knowing more about you app, it's difficult to give any advice.
Chris
|
|
|
|
|
I am writting a file compressing app.
But, for now, I'm just improving/optimizing the compressing algorithm that I'm using.
This algorithm as to writte a lot of bytes on several files (depending on the original file's size) and I'm using fwrite(), fopen(), fclose(), fseek() and fread() from stdio.h.
bottlenecks - I don't known what that is!
Is this helpfull? Thx!
|
|
|
|
|
|
My app spends most of its time reading from/writing to files. This is the main reason why I need a fast way to read/write files as the rest of the algorithm isn’t much time consuming, I’d say 85% of the time spent in the compressing algorithm is with files.
I need a fast way to read/write files in sequence.
thx.
hint_54
|
|
|
|
|
hint_54 wrote: bottlenecks - I don't known what that is!
It is a metaphor for trying to cram a bunch of work into a small passage. With a bottle, no matter its capacity, there is a physical limit to the amount of liquid that can pass through the neck (which is usually narrower than the bottle itself).
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
A memory-mapped file might save you a small amount of time.
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
hhhmmm... You are talking about DMA rigth? I don't know how to use it with files!
Thx!
|
|
|
|
|
|
hint_54 wrote: You are talking about DMA rigth?
No. DMA is a way to access memory independently of the CPU.
hint_54 wrote: I don't know how to use it with files!
A memory-mapped file is a spot in memory that can be accessed (e.g., open, close, read, write, seek) as though it were an actual file. By eliminating file I/O, a speed increase is (normally) realized. See these for examples:
http://www.ecst.csuchico.edu/~beej/guide/ipc/mmap.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngenlib/html/msdn_manamemo.asp
http://www.codeproject.com/file/xreverse.asp
http://www.codeproject.com/file/findidaddressbook.asp
http://www.codeproject.com/file/Memory_Mapped_Class___PBD.asp
http://www.codeproject.com/win32/cmemmap.asp
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
Yes, I know what you mean but isn’t that memory consuming for larger files?
hint_54
|
|
|
|
|
hint_54 wrote: ...isn’t that memory consuming for larger files?
I guess that depends on your definition of "larger files." I wouldn't think twice about using MMF for files several MB in size. In any case, you can restrict the mapping to only the portion of the file you are interested in.
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
There is no definition for larger files because this app is meant to be used by someone else, meaning that I can never know the maximum file size to be used (can be anything! And limiting that size is not an option.) and I can’t load portions of the file because the algorithm reads the file sequentially, woks on data (byte by byte) and stores the output way. But thx anyway 
hint_54
|
|
|
|
|
Using MMF can still improve performance, because you do not have to do the manual loading of data into a buffer - the OS basically does it for you. For example, if you were reading the file in 4KB chunks, you would be allocating a 4K buffer, copying from the file into that buffer, and then likely processing the contents of the buffer using the buffer's address. Using a MMF does that work for you.
If you want to impose a limit on the size of the MMF section you want to create, that is fine. Choose a limit, say 2MB (or 4Mb, or 64MB, whatever). If the file is 2MB or smaller, you can MM the entire file. Of not, you can MM 2MB sections of the file one at a time.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Thx! That has been VERY helfull!
|
|
|
|
|
DavidCrow wrote: A memory-mapped file is a spot in memory that can be accessed (e.g., open, close, read, write, seek) as though it were an actual file.
Sorry, but I think that is supposed to be the other way around. Memory-mapping something allows it to be accessed like normal memory (through a pointer). For example, if you had a memory mapped buttons/switches in your hardware (common on arcade games), you would be able to read the state of the switches by reading values from one or more specific memory addresses.
The same goes for files. If you memory-map a file, you get an address that points to some location in the file, and you can then access the contents of that file through the pointer.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
James R. Twine wrote: Sorry, but I think that is supposed to be the other way around.
Fair enough. Admittedly I've never used MMF before. Although I did change an application once that was reading a file a few bytes at a time to use CMemFile instead. Talk about a major speed improvement! Processing went from hours (some of the files were hundred MB in size) to just a few minutes.
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
A common beginner's mistake I see when doing file I/O is writing or reading one byte at a time (or a very small number of bytes). You can greatly increase I/O time by writing/reading good sized chunks at a time. Perhaps this is your issue?
How big to make the buffers is pretty much application dependant, but even going to say several K at a time can make a huge difference.
|
|
|
|
|
Actually a have been considering that fact for a reason:
As an algorithm restriction, I must deal with data byte by byte in order to accomplish the compression. So I begun wondering which was faster:
to read byte by byte or
to have to apply shift rights, bit wise orings and andings to extract the data (into a single byte) and then apply the rest of the algorithm on that byte which also includes those bit wise operations.
I would guess that the 2nd option is faster because it works only with registers and main memory but there quite a bit of those operations on the algorithm.
So my question is: does it really payoff to read memory chunks instead of byte by byte in this particular case?
Thx!
hint_54
|
|
|
|
|
You can read the file in large chunks and process that chunk byte by byte. Even when cached, doing disk I/O one byte at a time is painfully slow.
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
hmmm... I see! Thx a lot 
hint_54
|
|
|
|
|
Actually file I/O is never done on a byte level. The least bit of information that can be read from ,or written to a file is one sector. A sector is always an even multiple of 128 bytes, the most common sector size is 512 bytes.
So the runtime does buffer (at least) one sector (or more likely, a cluster).
I think the main reason for slowing down file reading a byte at the time, is the function call overhead and all the checks that has to be done, in the runtime, before the runtime can return the byte in question.
|
|
|
|
|
kakan [[]], a few things on that
kakan wrote: So the runtime does buffer (at least) one sector (or more likely, a cluster).
Can't you be more precise on which of those does the runtime buffers at a single shot? A sector or a cluster?
and
What if I read more than just a sector/cluster, will it buffer the necessary sectors/clusters with a single operation or will it take the same amount of time it would if I read the 2, 3, or more sectors/clusters on different operations?
thx!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
