Click here to Skip to main content
15,922,894 members
Please Sign up or sign in to vote.
3.27/5 (3 votes)
See more:
HI friends, i have c# program that creates excel files using text files.
but in larger text files the file creating process will be run lot of hours.
i think i can solve that problem by allocating more memory to that process.
i tried **heap and stack** methods. but i couldn't make it.
so please help me friends.
Posted
Comments
BillWoodruff 30-Dec-15 4:45am    
Well, if we could see your code that's doing the conversion, and see the format of the files you are converting, you might get better advice ... assuming the files are not a standard format.

If the computer performing the conversion is multi-core, you might consider trying to execute the conversion on a dedicated core.

Well, your comment showing code is marked 'Deleted, but I can still see it, and I can tell you right now that you should be using a StringBuilder to build strings on the fly, only converting the StringBuilder to 'string when necessary.

Suggest you move the code example to your original post, and then format it with CP's code editor.

Also: look on NuGet, searching for 'Excel: [^]: I see twenty libraries, many of which, I suspect, could provide code for file reading and mapping to Excel in ways similar to what you are doing.

I am also left wondering ... looking at the code sample ... if you could be using XML here for direct very-fast conversion ... but, perhaps, you have no control over the file format(s) you work with (?).
 
Share this answer
 
Comments
Arthur V. Ratz 30-Dec-15 6:36am    
Probably you've misunderstood. StringBuilder class, in this case, is a client-side mechanism to manipulate strings and it's used on the application side, not on the MS-Excel COM automation outprocess server. The main *CAUSE* why the application's process memory is pumping up is that an application normally manipulates the content stored in the data structures allocated on **heap or stack*. USING STRINGBUILDER CLASS DOES NOT ENSURE THAT A STRING IS ALLOCATE IN THE GLOBAL KERNEL MEMORY. THAT'S WHAT MY LATEST POST IS ABOUT. In this case, the GLOBAL MEMORY ALLOCATION itself is a slightly different topic. The memory allocated during an MS-Excel file creation is allocated on the server side in the MS-Excel application process.
Arthur V. Ratz 30-Dec-15 6:41am    
By the way, in your first post, you've written that if I would explain how to use the Win32API memory management functions to allocate buffers along with MS-Excel file creation I will get your +5. And when, I've done it, I've received just +3 ?!?!

Are you really not satisfied with my reply and explaination ?!?!

Write me please.
As far as I understand, you have to use the Win32API memory management
functions such as VirtualAlloc, VirtualFree to allocate buffers in global kernel memory space.

A few years ago, I've also encountered the same problem and using of these functions had worked.

Since you're programming in C# you just have to import these functions into your application.

Here's a link to MSDN resources VirtualAlloc[^]

Explaination: It's recommended to use memory management API such as VirtualAlloc functions to allocate buffers for the internal data structures that are used to store the data being processed by an application. In case when you're allocating memory on the app's **heap or stack**, it normally causes to pump up the process memory address space. Actually, *THIS* has nothing to do with MS Excel file creation which can be acomplished by using Win32 COM API or client-side COM wrappers supported by either MFC/C++ or C#/.NET Framework (e.g. in this case we simply don't actually need to allocate any buffers). Basically, an application (the most common scenario) fetches the data stored in the those buffers allocated in the global kernel memory context using VirtualAlloc function and then generates reports using the data retrieved from those app's data structures. Again, MS-Excel file creation has nothing to do with internal data structures buffers allocation. Important: The problem is that the multiple buffers allocated in app's **heap and stack** enlarge the amounts of the process memory being consumed (!!!). Thanks. Waiting for your comment.
 
Share this answer
 
v3
Comments
BillWoodruff 30-Dec-15 4:46am    
+4 a useful, on-topic, solution: add a little detail about how you used those functions with Excel file creation, and you get my #5.
Arthur V. Ratz 30-Dec-15 6:16am    
Hi. Sorry for my reply message late. It's recommended to use memory management API such as VirtualAlloc functions to allocate buffers for the internal data structures that are used to store the data being processed by an application. In case when you're allocating memory on the app's **heap or stack**, it normally causes to pump up the process memory address space. Actually, *THIS* has nothing to do with MS Excel file creation which can be acomplished by using Win32 COM API or client-side COM wrappers supported by either MFC/C++ or C#/.NET Framework (e.g. in this case we simply don't actually need to allocate any buffers). Basically, an application (the most common scenario) fetches the data stored in the those buffers allocated in the global kernel memory context using VirtualAlloc function and then generates reports using the data retrieved from those app's data structures. Again, MS-Excel file creation has nothing to do with internal data structures buffers allocation. Important: The problem is that the multiple buffers allocated in app's **heap and stack** enlarge the amounts of the process memory being consumed (!!!). Thanks. Waiting for your comment.
BillWoodruff 30-Dec-15 6:17am    
Hi Arthur, May I suggest you add the content in this reply to your original post ? Happy New Year ! Bill
Arthur V. Ratz 30-Dec-15 6:25am    
Of course. No problem. I'll make it.
Arthur V. Ratz 30-Dec-15 6:26am    
The content has been added. Would you care to review it.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900