XML file opening.

newguy

Well-known member
Joined
Jun 30, 2008
Messages
611
Location
Denver Co, USA
Programming Experience
1-3
I have a modal form that takes care of settings and options, I have 8 diff methods that open the file to make changes. My question; can and would it be ok to just open the file once(form load) make changes, save file(form closing)?
Speed is not the major concern as most of these methods run in less than 10 ms (per stopwatch). Good, Bad or Ugly?
 
Well it seems to works just fine to do it this way, as far as data being updated and no errors are thrown. I was just making sure no one saw any reason not to do this - this way.
 
It will work but why keep extra objects in memory that you dont have too. I would open & close as needed.
 
Does it actually close, there are no close/dispose methods for the XmlDocument object? I have my XML editor open with the file in question and it never receives any IO errors - unable to open as another process is currently using it, like you get when like notepad has a text file open and you try to read/write to it. It just asks me to reload it, then shows the changes. Its only 1 object for a modular form too. Just curious.
 
I was referring more to keeping the xmldocument object itself in memory that you didnt have too, not the actual opening and closing of the file itself.
 
That's why I asked my question in the last post. I know when my FileStreams are open and when they close. What exactly closes this object? With the setup I was talking about - I created the object, I loaded it, I made some changes, I saved the changes, I made more changes, I saved those changes. So with this I am not opening it or recreating the object. The documentation states it is cached memory - not that I know exactly what that means in the big picture, but how does it close? If I make many objects - 1 for each method don't I have many object instead of 1?

Thanks for the lively discussion, Tom. I am always ready to learn something new.
 
Last edited:
The XmlDocument class is an editable in-memory representation of an XML document. So you dont have the same problems of locking up a file like you said with other types of documents. Also the object doesnt have a IDisposable method to explicitly call to free its resources but it should be freed when it is no longer in use and falls out of its scope. I was just thinking that although you shouldnt have any problems with a global object, that could be one less thing accumalating in memory if you limited its scope to calling subs/events you need to use it. Sort of like if I filled a datatable delcared for the life of the program, it wouldnt effect other db users by locking up records with the database but is just extra clutter in memory that I dont need and can refill when I do. Either way its really neglible... :)

A bit different because of the object and the fact it does have a dispose method but there are many similar discussions about having a global database connection object for the life of the program session (something that was common practice to me previously). I agree with you that (to my thinking) it doesnt make sense to create a new object with each & every call to the database rather then having one connection object already made (and im not referring to leaving the connection state open only keeping the obect itself in memory) but seeing so much advisement against it; prompted me to do some testing and although I still dont see the why to it; the testing I did, had faster results with creating a new object with each use and disposing of it at that level.
 
I can't use xl.dispose() - 'dispose is not a member of Xml.XmlDocument'??? I see that if I try Using/End Using it mentions as you stated it must Implement IDisposable. This is why I am trying to understand this object to use it correctly. What say thee...
 
I would think it is a combination. Even if your file is blank or contains very little data, objects such as an XmlDocumtent, Dataset or Datatable still take up resources just to be generated.
 
That should be the next thing to be implemented into the Framework. Something to measure all of our objects in realtime - so we can develop better or at least understand the demands we are imposing. Thanks Tom...
 
That should be the next thing to be implemented into the Framework. Something to measure all of our objects in realtime - so we can develop better or at least understand the demands we are imposing. Thanks Tom...

I think they leave that out to hide alot of mistakes... If you want to do an experiment, create a project with 2 forms. Put a button on form1 and in its event show form2. Go into Task manager, Processes tab and watch the memory continue to grow every time you show the blank form. For additional data, you can click on the View menu and choose Select Columns which gives some additional options such as peak memory usuage. After that add a datagridview control and fill it with some data. Then just continue to move your mouse cursor back and forth over the data.

I would love something that detailed all the objects in memory, there size and values.....
 
I have checked the processes to see how much my whole program is using in debug(close enough) - at least I feel good that it is not to high. ;)
 
Back
Top