VirtualAlloc,GlobalAlloc,HeapAlloc,..what to use in my case,...
in [Visual C]
|
Prev: Warnings about deprecated / insecure function usage
Next: App built by VS2008 causes "side-by-side configuration"-error in Vista
From: Joseph M. Newcomer on 8 Mar 2008 21:48 See below.... On Sat, 8 Mar 2008 17:20:13 +0100, "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote: >Hi Alex, > >>The real question here is why do you need `VirtualAlloc' at all? >Why not and i also want the MEM_WRITE_WATCH Option >for some special purpose. I must watch some special areas of >the memory. There is a bit more in going on my application, nit >just read and write some files and streams. **** I keep being amazed by people who fail to define the entire problem, and want a solution to some part of it. OK, you've justifed VirtualAlloc. You could have done this at the start. ***** > > >>You always call it with `MEM_COMMIT' and `PAGE_READWRITE' flags making it >>eventually indistinguishable form regular `operator new' or `malloc'. > >the C++ "new" Operator is no option for me, because it is a plain >C Application and i dont want to mix it up with C++ heap memory >stuff. > >>Actually you're making it worse since you miss all optimizations that CRT >>may enable (like Low Fragmentation Heap, for example). > >I can still use HeapCompact(...) if i need to... > >>I suggest you at least to try your code with regular `new' and `delete'. > >No C++,... > >Thanks,... > >Regards > >K. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Kerem G�mr�kc� on 8 Mar 2008 21:50 Hi Nathan, >new and malloc both use the same heap, provided by the C Runtime >library, which is used by C and/or C++ code. They can coexist just >fine, no matter which language requested the memory, and nothing will >be 'mixed up.' Plus, your code will be far more portable to other >(i.e. non-Win32) systems. Thank you i know that, but i hold my code strictly in C and dont want to mix it with c++ language features. Yes, in general there is no difference using them, but this time its a language thing,... Regards K. -- ----------------------- Beste Gr�sse / Best regards / Votre bien devoue Kerem G�mr�kc� Microsoft Live Space: http://kerem-g.spaces.live.com/ Latest Open-Source Projects: http://entwicklung.junetz.de ----------------------- "This reply is provided as is, without warranty express or implied."
From: Kerem G�mr�kc� on 8 Mar 2008 22:21 Hi Joseph, >I keep being amazed by people who fail to define the entire >problem, and want a solution to some part of it. I dont understand,...if i could define the entire problem, be sure that i had solved it by my own. Thats why i asked this here, because it was not clear to me, why my mem usage decreased, even when i deallocated it. As told before, i have several wrappers around the VirtualAlloc/HeapAlloc and it was a implementation mistake i made. I passed a wrong parameter to the VirtualFree, but i was not aware of it, because it was no longer the original call to VirtualAlloc, it was wrapped by my function call,... >OK, you've justifed VirtualAlloc. You could have done this at the start. Was this necessary,...the original question was: Why does my application consume even more memory and why does it seem that it uses more and more memory, even for the case i free it and ensure clean allocation/freeing, even by securing things with SEH and Syncronization. Ok, i didnt tell SEH and Sync, but it was not necessary. Alexander pointed at the VirtualFree and yes, it was the right place to look. The wrappers look like "LPVOID vi_virtual_alloc(SIZE_T)" and vi_virtual_free(LPVOID). The Internals of the wrappers include some extra operation on the memory before it will be freed or returned to the caller. I passed a wrong parameter to VF, and thats because i overloaded a function and accidentally used its old parameter from the base function.... Everything is now fine.... Thanks! Regards K. -- ----------------------- Beste Gr�sse / Best regards / Votre bien devoue Kerem G�mr�kc� Microsoft Live Space: http://kerem-g.spaces.live.com/ Latest Open-Source Projects: http://entwicklung.junetz.de ----------------------- "This reply is provided as is, without warranty express or implied."
From: Nathan Mates on 8 Mar 2008 23:33 In article <#ybgPCZgIHA.4712(a)TK2MSFTNGP04.phx.gbl>, Kerem G�mr�kc� <kareem114(a)hotmail.com> wrote: >>new and malloc both use the same heap, provided by the C Runtime >>library, which is used by C and/or C++ code. They can coexist just >>fine, no matter which language requested the memory, and nothing will >>be 'mixed up.' Plus, your code will be far more portable to other >>(i.e. non-Win32) systems. >Thank you i know that, but i hold my code strictly in C >and dont want to mix it with c++ language features. Yes, >in general there is no difference using them, but this time >its a language thing,... As I pointed out above, malloc is a perfectly reasonable function to use. It's 100% C, no C++. Go read your K&R if you don't believe me. Plus, malloc is portable to other systems just fine. As long as you balance your malloc/free calls, then your app should behave fine. Nathan Mates -- <*> Nathan Mates - personal webpage http://www.visi.com/~nathan/ # Programmer at Pandemic Studios -- http://www.pandemicstudios.com/ # NOT speaking for Pandemic Studios. "Care not what the neighbors # think. What are the facts, and to how many decimal places?" -R.A. Heinlein
From: Joseph M. Newcomer on 9 Mar 2008 00:42
See below... On Sun, 9 Mar 2008 03:47:53 +0100, "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote: >Hi Joseph, > >>Why use VirtualAlloc at all? Doesn't make much sense to me to see this >>low-level call in >>use; it is used in rare situations (I've used it twice in over 15 years of >>Win32 >>programming). > >I think i posted the reason, because i need to keep track of several regions >of the >memory to get signaled on change/read/write/access... **** Yes, I saw that in a later part of a thread. But you should have said this up front to make your use of VirtualAlloc make sense **** > >>There is a horrid fascination with people reporting the amount of physical >>memory on their >>machines; this is almost totally irrelevant to the question of running out >>of memory, >>because you are not running out of physical memory, you are running out of >>virtual memory. > >I think i said that i know what realy physical memory and the virtual adress >space means >and thas why i said my application sizes tremendously its "virtual" memory. >I can have a >application that requests 500MB Ram on a system with 256 MB real physical >ram, it >would work, but my system paging file would also "work",... **** So why should anyone care how much physical memory you have on your machine? It has nothing to do with answering the question or causing the problem **** > > >>Use 'malloc' if you are programming in C or 'new' if you are programming in >>C++. >>I would not consider VirtualAlloc, GlobalAlloc or HeapAlloc for any of >>these situations. > >Then let me ask you: Why are these functions available to the users, if i >should not use them? **** Just because an API exists does not say that its use represents best practice, good practive, or even acceptable practice. I once had a programmer insist that VirtualAlloc was the fastest way to allocate memory! (He apparently could not understand that a kernel call is several orders of magnitude worse peformance than a subroutine call). In general, and without any other justification, VirtualAlloc is not a sensible way to allocate memory. ***** >VirtualAlloc is interessting to me, because of its "notification" >features,... **** Yes, and that is not the general case. That is a very specific case, for which the API is useful. But since you did not state this requirement as part of your original problem statement, the assumption is that you chose it randomly because it looked like it might allocate memory in a useful way. In many of my posts, I will add the qualification "except in rare and exotic circumstances". The need to detect data changes falls deeply into the rare-and-exotic category. **** > >>For that matter, one of the fastest ways to do this would be to scan the >>directory, find >>the largest file, allocate one buffer of that size, and use it for all the >>other file >>Each time you open a file, you double-check that the memory you allocated >>is still large >>enough (the file might have grown, but once you open it exclusive, it isn't >>going to get >>any larger). If it isn't, you reallocate at that point, otherwise you >>retain your >>allocation. This avoids issues of memory fragmentation (if you're not sure >>what this >>means, read my essay on storage allocation on my MVP Tips site) > >This is a really good idea, at least i would not make my application >alloc/free >free like hell,... **** Some years ago, I wrote what was then, and might still be, the world's fastest storage allocator (it was so fast that we considered compiling the equivalent of 'malloc' inline for most cases [but it was in a single-threaded environment]). A few weeks after its release, one product group came to me and said that my allocator was the cause of all their performance problems, which I did not believe. They brought me the performance output, which showed a massive spike at the storage allocator. So I reached in with the debugger and set a flag bit in a configuration word (used in the debug version, which they were running). Upon completion, we saw that the reason the storage allocator was a performance bottleneck was that it was called over 4,000,000 times. It was a situation much like yours, where a block of storage was allocated each time through a loop. The solution was to declare a stack variable of size N, and each time through the loop, see if a block >N was needed. If so, a block of max(2*current_size, computed_new_limit) was allocated, and left in place until *it* became too small, in which case the same algorithm was used to allocate a new block. The result was that from that loop the allocator might be called four (4) times, in the worst example we ran (and it took only one reallocation per loop in the worst case, 0 in the typical case). The allocator disappeared as a performance consideration. joe **** > >Regards > >K. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |