New ghpython issues: crashing, multithreading performance


(Andrew Heumann) #1

att: @stevebaer

I have a few questions/issues with the latest release of ghpython.

First - I have an issue with the python editor crashing intermittently. This has even happened when making a modification to the script @stevebaer provided on his blog: “ghpython_components_sample2.gh”. Simply upping the plane count to 300 and making a modification to the script (adding “print(‘hey’)” after “slices = ghpythonlib.parallel.run(slice_at_angle, planes, True)” caused rhino to crash. I cannot cause it to happen consistently, but I have noticed it several times now.

Second - I only rarely have success achieving a performance improvement by multi-threading a function with python. In the attached example, the parallel python script is always slower than both a non-parallel version of the same script (switched with the attached toggle) as well as the original component itself. Am I structuring my script wrong?

Third (maybe most important) - I am concerned that some sort of memory leak is occurring. I have now noticed several times that every time a complex, multithreaded python script runs, its execution time is significantly slower than the previous time, even with identical data. In the attached definition, when I enable the python component the first time, it calculates in 8.4 seconds. If I repeatedly reconnect one of the inputs, it goes up to 13.8, then 24.8, then upwards of 2 minutes. See the attached video for one example of such a run cycle. I have edited the video for speed but you can clearly see the difference.

Finally - I notice that sometimes with mutlithreaded python scripts, the component appears to update prematurely - downstream components will update (like the panel in the video) before the calculation is complete.

pyMT_Isovist.gh (19.6 KB)
pythonMTIssue.mp4 (571.0 KB)


(Steve Baer) #2

When Rhino crashes, do you get any sort of information about what the cause of the crash was?

As far as the slower times with IsoVist, you do appear to be structuring the function correctly. I’m not too knowledgeable about that specific component so I’ll have to dig through the grasshopper code to figure out what is going on. It may take some time for me to give you any decent answer.


(Andrew Heumann) #3

Sometimes it just crashes flat out - other times I’ve gotten out-of-memory errors.


#4

Hi @stevebaer,

I have just experienced the same Rhino crashing problem by using .CurveOffset() method with parallel module.
This is the first time I experienced Rhino crash using it (the parallel mode).
Any ideas why is this happening?

Here is the error message I get when I move around the “d” slider:

Rhinoceros 5.0 (32-bit) has encountered a problem and needs to close.  We are sorry for the inconvenience.

When I click on “debug” the following error window appears:

“To see what data this error report contains click here” reveals this:

“To view technical information about the error report, click here” reveals this:

C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\WER6fe8.dir00\drwtsn32.exe.mdmp
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\WER6fe8.dir00\appcompat.txt

I tried searching for this two mentioned files: drwtsn32.exe.mdmp, appcompat.txt but couldn’t find them. Nor WER6fe8.dir00.

These are PC specifications:

  > Mainboard : MSI P4M890M3-V (MS-7255)
  > Chipset : VIA P4M890
  > Processor : Intel Core 2 Duo E4300 @ 1800MHz
  > Physical Memory : 2048MB (2 x 1024 DDR2-SDRAM )
  > Video Card : ASUS EAH4670 series
  > Hard Disk : Seagate ST3320820AS (320GB)
  > Operating System : Microsoft Windows XP Professional 5.01.2600 Service Pack 3 (32-bit)
  > DirectX : Version 9.0c  (May 2010)
Rhino 5 SR5 (32 bit)
Grasshopper version: 0.9.0064
ghPython: 0.6.0.3

Any thought why this may happen?
Thank you.

offsetCurve.gh (9.1 KB)


Downloading .gh files from this site