Hi all, hope you are having fun! :)
I am making "the tool to end all tools", and in the process I am modifying thousands of elements...... and that builds up the "Commit Charge", and eventually crashes.
I must prevent my tool crashing due to memory overuse! I have seen that if I manually compress the designfile, the "Commit Charge" is lowered alot, and the "undo" option is no longer available. Thus I speculate that the memory issue is related to uStation wanting to provide an undo option. I don't need an undo option at all. Can I disable the undo, and would that be a solution?Is there anything else I can do to preserve memory? I am careful about setting objects to nothing after use in my code, but all tips and tricks regarding memory management is really very very welcome!
Regards,/Torben
Hi Torben,
will be the next phase of your development "a CAD tool to end all CAD tools"? :-)
But seriously - when exactly your VBA crashes? As usually, a piece of code would be helpful. Do you change your thousand of elements in one loop?
What do you mean by "Commit Charge"? I know roughly this term but not sure about your situation.
An idea only: DoEvents() can help if you do too many thing in one loop.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Hi Jan,
Next phase.. hehe, well for me this project is definitly the biggest (and coolest) I have done so far. It scans and imports automatically from a lot of sources. Calculates and outputs nicely, what used to take weeks, in mere minutes! Its pretty cool - sadly the bosses have no clue... heh - Yeah, my next tool should be something in the lines of me getting total world domination.. Now where did I put that turnBloatedEgoToGold() ;)
I am glad you are asking questions, as I have been staring at this for way to long:
By "Commit Charge" I mean the value seen in the Task Manager. bottom right. I believe it indivates something about memory use.. It does seems to indicate when uStation will crash. Here it crashes around the 2000/5000 mark.
I have allready alot of doevents here and there. Mostly for making sure forms close before my stuff happens. I will try it some more though.
Yes, I change thousands of (huge) elements in loops/for..nexts/with element in elementenumerator.. Nothing seems to behave better than others ?!
Thanks
/Torben
System: Win7 64bit 16GB Ram - microStation V8i SS3 08.11.09.578. + PoinTools CONNECT. - Intel i7-4800MQ CPU@2.70GHz, 4 core / 8 Logic proc.
OK, and do you use DoEvents inside loops/for--nexts/with element?
To be honest I have to say I have not too much experience with these kind of things, but I remember I developed a macro for Bentley Map that creates quite a lot of XFM elements in for cycle and it crashed. The problem was solved I added condition to call DoEvent for every xth element inside loop, so VBA / COM / Bentley Map communication had enough time and resources to do all required tasks. May be it can be the way?
I thinka general advice is to split all huge tasks into smaller one. No technology is able to process and manage unlimited requirements and VBA is one from the weakest.
I will try with more doevents. But my crash is not really happening inside the loops. It is happening because this "Commit Charge" keeps building up, and is never released again. So, when I run any of my macros again, more memory is wasted untill it finally gives in (uStation that is)
As mentioned earlier, if I manually "flush" the file (compress it so the undo information is deleted) the memory is released.
I still suspect uStation and it's undo capability is to be blamed?
Unknown said:I still suspect uStation and it's undo capability is to be blamed?
Point the finger of guilt elsewhere. MicroStation can handle huge quantities of data (i.e. memory).
Microsoft designed VB and VBA to be rapid application development (RAD) tools. Those languages were and are extremely successful in meeting that design goal.
Microsoft did not intend VB or VBA to be able to create high-performance applications. There are too many overheads, and so many pitfalls. High performance means high speed and/or huge data capability. VB and VBA satisfy neither of those requirements.
For a high-performance application, choose a language such as C++ that compiles to native code. A well-designed application built with C++ can handle huge amounts of data and can handle it fast.
Regards, Jon Summers LA Solutions
If that is so Jon, Then why is the memory released by uStations "File->Compress" Option?
Also, what are the pitfalls when it comes to VBA and uStation?
Unknown said:Why is the memory released by uStations "File->Compress" Option?
Because MicroStation stores modified and deleted elements. They remain in the internal caches until you exit or compress the file. If VBA is referencing a modified or deleted element then it is using additional memory.
Unknown said: What are the pitfalls when it comes to VBA and uStation?
The same as using VB or any other VBA. It's too huge a topic to go into here. There are plenty of web sites where you can find information.
Why is the memory released by uStations "File->Compress" Option?
[/quote]
From my point of view, it looked indeed as if microstation had an issue. I believed it had to do with microstation storing modified and deleted elements. Continued to fill this internal cache with garbage.I see that when I manually recolor thousands of elements, the Commit Charge is not really moving, even when deleting all elements - nothing is added to the Commit Charge...
So I am doomed then..
I will try to make a short code sample that causes microstation to crash, then perhaps you guys will be so kind as to point some fingers where the blame is due.
This little testfunction is making the Commit Charge climb ever so slowly (by a few MB each run, so its safe to run):
Function fillUpTheCommitCharge() Dim e As Element, dl As DLong For i = 1 To 10000 Set e = CreateLineElement2(Nothing, Point3dFromXYZ(636627, 117666, 67), Point3dFromXYZ(636669, 117675, 1)) ActiveModelReference.AddElement e e.Color = RGB(1, 2, 3) dl = e.ID ' get the element by id Set e = Nothing Set e = ActiveModelReference.GetElementByID(dl) ActiveModelReference.RemoveElement e Set e = Nothing Next iEnd Function
Adding a DoEvents in the for/next does nothing but make it really really slow.
I hope someone can help me overcome this increase..In my actual project the elements are much more complex and the increase is faster.
What I see when I run one of my huge modificational macros is:Commit Charge goes from 1100 -> (peaks at ~1700) -> makro finishes, microstation hangs for a while, the commit change drops to 1250..
With a doevent in the mix, the commit charge peak is only at about 1400, but it is still increased from 1100->1250 when the macro is finished.
At around 2000M/5980M microStation crashes with an empty dialog box.
Unknown said:Adding a DoEvents in the for/next does nothing
DoEvents is useful where you are updating a UI (e.g. a progress bar) while performing a computationally intensive task. Where you are not updating a UI widget, as here, then DoEvents does nothing except waste CPU cycles.