|
You have been of great assistance.
I will look into what you mentioned.
Thanks alot!
|
|
|
|
|
thanks very much
but am sad to tell you that iam using C# and not familiar with VB
so maybe if you can supply me with some C code it would be good
sorry for the inconvinience
regards
|
|
|
|
|
|
Well, you have 400 records, not 7200, unless your database is laid out funky... You have 7200 total fields of data.
The DataTable class has quite a large overhead compared to an Array. So, if an array works for you, great! If not, you may want to look into a Generic collection solution.
glumlord wrote: Processor - While storing to the Datatable the processor is at 15-30%
30%?? Who cares??
glumlord wrote: Memory - Even after flushing the memory using a class I have my application is taking 6MB now instead of roughly 800k-1024k it was before.
Memory as measured by what?? Please don't tell me you used TaskManager! It's kind of lying to you when it comes to .NET apps. You really have to understand what TaskManager is looking at. If you want more accurate numbers of what your APPLICATION is using, use Performance Monitor and the .NET Memory counters.
Task Manager is showing you what is RESERVED for your process, not necessarily "in use". .NET CLR applications run inside a "virtual machine", not unlike what Java uses. What you're seeing is the memory that is sitting in the Managed Memory Pool for your application inside the "virtual machine". The .NET CLR maintains a pool of memory to speed allocations of future objects. It tunes itself to try and predict how your app is going to use memory in the future, based on what it's done in the past. It gets this memory from Windows and adds it to the Managed Pool. If Windows starts running low on memory, it can ask the .NET CLR to free up however much memory it needs and the CLR will be more than happy to return whatever it can spare.
Basically, unless you have a condition where your app runs the machine out of memory, or is using excessive amounts of memory, you're worrying about nothing. The .NET CLR does a very good job of managing memory and playing nice with the rest of the system.
|
|
|
|
|
Dave Kreskowiak wrote: Memory as measured by what?? Please don't tell me you used TaskManager! It's kind of lying to you when it comes to .NET apps. You really have to understand what TaskManager is looking at. If you want more accurate numbers of what your APPLICATION is using, use Performance Monitor and the .NET Memory counters.
I do use Task Manager and I added all the columns that refer to Memory. I compared that to the previous version of my application using Arrays. It may not be accurate completely but I would beg to differ if you think it's useless  It tells me that the version with Datatables instead of an Array is taking 6 x as much memory.
I use the following to flush memory, which I have good luck with in the past.
Public Class MemoryManagement<br />
<br />
Private Declare Function SetProcessWorkingSetSize Lib "kernel32.dll" ( _<br />
ByVal process As IntPtr, _<br />
ByVal minimumWorkingSetSize As Integer, _<br />
ByVal maximumWorkingSetSize As Integer) As Integer<br />
<br />
Public Shared Sub FlushMemory()<br />
GC.Collect()<br />
GC.WaitForPendingFinalizers()<br />
If (Environment.OSVersion.Platform = PlatformID.Win32NT) Then<br />
SetProcessWorkingSetSize(Process.GetCurrentProcess().Handle, -1, -1)<br />
End If<br />
End Sub<br />
<br />
End Class
Dave Kreskowiak wrote: glumlord wrote:
Processor - While storing to the Datatable the processor is at 15-30%
30%?? Who cares??
It does matter because this app is on every single desktop pc in our organization and opens at windows startup when processor time will directly affect how quickly a user can use his/her pc.
Dave Kreskowiak wrote: The DataTable class has quite a large overhead compared to an Array. So, if an array works for you, great! If not, you may want to look into a Generic collection solution.
Thanks for that suggestion, I'll do some research into that. I appreciate any help I can get as most of this stuff I have learned from reading and am still quite wet under the ears.
|
|
|
|
|
glumlord wrote: I do use Task Manager and I added all the columns that refer to Memory. I compared that to the previous version of my application using Arrays. It may not be accurate completely but I would beg to differ if you think it's useless
Considering TaskManager is showing you the memory that is reserved by the .NET CLR and not your actual application usage - yeah, it's pretty useless. Yes, TM can show your app as using 100MB of RAM when it's really only using 18MB. What would you think about it if you saw that??
BTW: I got that on a 64-bit machine with 64GB of RAM in it.
|
|
|
|
|
Dave Kreskowiak wrote: 30%?? Who cares??
The user probably cares; he is sitting in front of the monitor waiting 23 seconds for things to happen. With a CPU load of 100% it might last only 8 seconds. And with a better design probably only a fraction of that.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Sadly, what doesn't show up in the 30% is all the idle time the CPU has waiting for disk I/O to complete.
If the CPU is at 30% during all of this, there really isn't too much he can do, other than redesign and try and bypass the off-CPU bottleneck.
|
|
|
|
|
Disk I/O can be a factor, but I understood with arrays, i.e. without DataTables, it only took 2 seconds; so everything exceeding that needs scrutinized.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Luc Pattyn wrote: it only took 2 seconds; so everything exceeding that needs scrutinized.
I wonder about his users! If they're complaining that it takes 2 seconds longer to get a Desktop they can use, they really need professional mental help! 
Where I work, it can take upwards of 10 minutes (worst case) to get into a machine on the first login! My laptop takes 5 minutes to get to the point where I can use it! 23 seconds is nothing... 
|
|
|
|
|
Dave Kreskowiak wrote: I wonder about his users! If they're complaining that it takes 2 seconds longer to get a Desktop they can use, they really need professional mental help!
Where I work, it can take upwards of 10 minutes (worst case) to get into a machine on the first login! My laptop takes 5 minutes to get to the point where I can use it! 23 seconds is nothing...
I feel for ya! Thats horrible, luckily we have all new machines here and usually within 10 seconds of logging in the users is fully able to use machine.
I'm also in charge of the login scripts and we keep the stuff it does to a minimum. User impact will be minimal but there is a perception with the users that their computers are slow if we have stuff like this happening. They don't understand it's poor programming, nor do they care.
I actually started writing out console.writeline with time stamps through the loop process of writing the data to the datatable and it was taking 80-120 ms per user in loop. It takes 10 ms for example to create a new row.
I did change two things and was able to shave about 2 seconds off. Something doesn't quite seem right because I was talking to a web developer friend up here and they have a web database that can write/query 40k records in about 5 seconds.
He said my code looked fine also. I'll mess with this in a day or two when I have more and post an update for those of you curious.
Either way I appreciate all the advice everyone has given.
|
|
|
|
|
Hi ,
I have a asp.net application which was built in vs 2005 sp using .net framework 2.0 sp1.
when i used the same application in vs 2005 RTM with .net framework 2.0 sp2 , am getting a
lot of errors (compilation).
Is the change in service packs effects this scenario in any way?
Thanks in advance!
suchiT
|
|
|
|
|
Sounds likely. If it worked before, and doesn't work now and the only thing that's changed is the service pack then it stands to reason that this is the problem.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
look at the first compilation error first. Maybe show us some...
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
|
And what does this have to do with the .NET Framework??
|
|
|
|
|
|
What are you trying to do with this?? Have you added other files as resources??
|
|
|
|
|
HOW CAN I ADD FILES DYNAMICALLY TO DYNAMICALLY CREATED application as Resources .Please Help I want matters to be done dynamically
modified on Tuesday, May 12, 2009 2:03 PM
|
|
|
|
|
You can try this tool[^]. I'm not going to say it'll work, nor will I even support the idea. What you're doing is not an accepted practice for a production quality application. Nor is there very much reason to do what you're attempting. Files like this are best left outside the .EXE since modifying an .EXE always risks damaging it to the point it'll never run again without being scrapped and reinstalled.
|
|
|
|
|
Hello,
my MDI application includes child windows having the FormBordStyle property set to SizableToolWindow, so the Maximize and Minimize boxes are hidden.
Nevertheless, the child windows can still be maximized by double-clicking on the title-bar; how can I inhibit this feature?
Thank you
|
|
|
|
|
Did you change the FormBorderStyle of this window to FixedToolWindow, or SizableToolWindow?? Hint, hint...
|
|
|
|
|
I changed the FormBorderStyle to SizableToolWindow, since resizing the child windows (by dragging a corner or a border of the window) is allowed in my application.
I just want to prevent child windows from being maximized as a consequence of a double-click on the title-bar.
|
|
|
|
|
In that case, you're going to have to handle the Resize event of your child form. In that handler, check for the windowstate property, and set it back to Normal if it is Maxmimized.
|
|
|
|
|
That's exactly what I was looking for!
Thank you very much.
Max
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
