At the moment I’m using the Bumblebee package (@Konrad_Sobon) to pull excel data and I’m running into memory issues with repetitive runs that have multiple read blocks. It looks like each read call is starting a new instance of the excel app and it remains open after the data has been read. Is this the current behaviour of the Bumblebee package? Anyway to call .Quit after the data has been read that anyone can share? I imagine this will require some caching.
Yes, every time a file is read an instance of Excel is open and then when read is successful it is being closed. This is the method that I use to do that:
def ExitExcel(xlApp, wb, ws): # clean up before exiting excel, if any COM object remains # unreleased then excel crashes on open following time def CleanUp(_list): if isinstance(_list, list): for i in _list: Marshal.ReleaseComObject(i) else: Marshal.ReleaseComObject(_list) return None xlApp.ActiveWorkbook.Close(False) xlApp.ScreenUpdating = True CleanUp([ws,wb,xlApp]) return None
You don’t have to call
xlApp.Quit() if workbook was closed properly.
If there was an exception thrown during this process the open excel app will linger behind. In that case it makes sense to collect it and call Quit() on it like so:
except: xlApp.Quit() Marshal.ReleaseComObject(xlApp) # if error accurs anywhere in the process catch it import traceback errorReport = traceback.format_exc() pass
I do that in the exception handling part of ReadExcel node.
If you are experiencing a massive slowdown, I am sure I can relate. I get it too, but that’s because every time you hit run Dynamo loads in all of the libraries that are being used by the Python node implementation. There is a massive performance hit on that side of things, but there is nothing I can do about that.
I think @Dimitar_Venkov might know more about this slowness associated with Python implementation in Dynamo. I haven’t looked at it closely.
Hmm, on my end the ExitExcel() or Quit() method don’t seem to be ending the instance of Excel. I’m pulling from 10 ranges in an excel file and there seems to be no issue reading the data. After running the graph, the excel processes remain and even after closing out of Dynamo and Revit they still linger. I’m using Excel 2016 and Dynamo 1.1 - any known issues there?
I don’t have Dynamo 1.1 installed nor have I ever tested on it. I don’t think I have been testing on Excel 2016 either. I have 2013 at home and that’s what I am running on.
The lingering excel processes (unreleased COM objects?) only occur when a list is passed as one of the parameters. For example, two strings for the range or two strings for the range and two strings for the sheet name. Most the development I’ve done is with C# nodes, does Dynamo handle lacing differently for Python nodes?
Mhmmm, that is indeed an interesting finding. Now, that I think about it, my implementation might have a mistake in it. I should be disposing of each worksheet after I am done with writing data to it, otherwise it will be left behind as you noticed. I think since I am doing the clean-up just once at the end, it means that I might have missed that.
Thanks for noticing and investigating it. Can you post this to Bumblee github page under issues? https://github.com/ksobon/Bumblebee/issues
Ps. So obviously it wouldn’t just be a Worksheet, but also a Range or any other excel object that needs to be released. COM interop is a bit sensitive about that and leaving even a Range object behind that wasn’t disposed will show up in task manager as an Excel process. I think I need to do another run at Bumblebee and clean it up a bit.