Regression: speed of creating objects (MSVC2013) #40450

New Issue

S A · 2014-05-31T17:55:09+02:00

S A commented

2014-05-31 17:55:09 +02:00

System Information
Operating system and graphics card: Windows 7, NVIDIA GeForce GTX 550 Ti

Good day! I would like to draw your attention to a very unpleasant moment.
A new test release blender-2.71 creates (using the same
script) objects more than 2 times slower than blender-2.70!

Sincerely, sant_a.

**System Information** Operating system and graphics card: Windows 7, NVIDIA GeForce GTX 550 Ti Good day! I would like to draw your attention to a very unpleasant moment. A new test release blender-2.71 creates (using the same script) objects more than 2 times slower than blender-2.70! Sincerely, sant_a.

S A commented

2014-05-31 17:55:09 +02:00

Changed status to: 'Open'

S A self-assigned this 2014-05-31 17:55:09 +02:00

S A commented

2014-05-31 17:55:09 +02:00

Added subscriber: @sant_a

Bastien Montagne commented

2014-06-01 16:21:18 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2014-06-01 16:21:18 +02:00

What are we supposed to do with such a report? Write our own 'add object' script? Please always attach needed files to reproduce the issue.

S A was unassigned by Bastien Montagne

2014-06-01 16:21:36 +02:00

S A commented

2014-06-01 20:54:19 +02:00

Ok. Send You the sample file add objects. In the blender-2.70a-windows64 objects are added ~ for 7 sec., and in blender-2.71-testbuild2-win64 - 43 sek.!!!

S A commented

2014-06-02 08:29:39 +02:00

Here is the code of the script:

import bpy
import time

bpy.ops.object.delete({'selected_bases': list(bpy.context.scene.object_bases)})

for mesh in bpy.data.meshes:

  mesh.user_clear()
  bpy.data.meshes.remove(mesh)

time_start = time.time()

for i in range(1000):

  bpy.ops.mesh.primitive_cube_add()

print("My Script Finished (sec):", time.time() - time_start)

Today I saw that you updated the built-in Python (3.3.0 --> 3.4.0.).
Perhaps this is a new release of Python became so clumsy?

Here is the code of the script: import bpy import time bpy.ops.object.delete({'selected_bases': list(bpy.context.scene.object_bases)}) for mesh in bpy.data.meshes: ``` mesh.user_clear() bpy.data.meshes.remove(mesh) ``` time_start = time.time() for i in range(1000): ``` bpy.ops.mesh.primitive_cube_add() ``` print("My Script Finished (sec):", time.time() - time_start) **** Today I saw that you updated the built-in Python (3.3.0 --> 3.4.0.). Perhaps this is a new release of Python became so clumsy?

Bastien Montagne commented

2014-06-02 13:58:11 +02:00

Can’t confirm this here on linux, 2.70a and 2.71both take about 17secs on a rather recent and powerful laptop…

However, there is a much bigger change than new py3.4 on windows: we switched to new VC2013 compiler (2.70 was built with VC2008)… Than could very well be the culprit?

Can’t confirm this here on linux, 2.70a and 2.71both take about 17secs on a rather recent and powerful laptop… However, there is a much bigger change than new py3.4 on windows: we switched to new VC2013 compiler (2.70 was built with VC2008)… Than could very well be the culprit?

Martijn Berger was assigned by Bastien Montagne

2014-06-02 13:59:01 +02:00

Bastien Montagne commented

2014-06-02 13:59:01 +02:00

Martin, can you please have a look at this? thanks! :)

Willi commented

2014-06-02 19:36:35 +02:00

Added subscriber: @willi-2

Willi commented

2014-06-02 19:36:35 +02:00

AMD Phenom II 965 BE (3,4 GHz):

blender-2.70-3e6c734-win64: 16.8 s

Narrowed it down to these two versions:

blender-2.70-be980b9-win64 (May 16): 6.9 s, 6.5 s
blender-2.70-07e8096-win64 (May 18): 14.8 s, 13.3 s, 15.1 s, 14.4 s

So, reproducable here.

AMD Phenom II 965 BE (3,4 GHz): blender-2.70-3e6c734-win64: 16.8 s Narrowed it down to these two versions: blender-2.70-be980b9-win64 (May 16): 6.9 s, 6.5 s blender-2.70-07e8096-win64 (May 18): 14.8 s, 13.3 s, 15.1 s, 14.4 s So, reproducable here.

S A commented

2014-06-02 19:53:22 +02:00

I agree with mont29. And here:

 http://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/

inform that VC2013 does not maintain compatibility runtime code to older versions VC for Win64.

Will try to win32.

I agree with mont29. And here: ``` http://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/ ``` inform that VC2013 does not maintain compatibility runtime code to older versions VC for Win64. Will try to win32.

Martijn Berger commented

2014-06-02 22:41:28 +02:00

I can also reproduce the issue.

16.18 vs 30.52 for me under wine.

about that supposed vc 2013 problem ->
Why has nobody else reported this compatibility problem?

  Most people haven’t upgraded to VC++ 2013 yet
  It’s 64-bit only
  It only happens if you mix VC++ 2010/2012 with VC++ 2013 binaries
  Many classes don’t have virtual functions.
  Most classes don’t contain __m128 members.
  Those that have virtual functions often inherit from classes that have virtual functions (interfaces) which avoids the bug.

We do NOT mix vc2013 with any other vc++ code

I can also reproduce the issue. 16.18 vs 30.52 for me under wine. about that supposed vc 2013 problem -> Why has nobody else reported this compatibility problem? ``` Most people haven’t upgraded to VC++ 2013 yet It’s 64-bit only It only happens if you mix VC++ 2010/2012 with VC++ 2013 binaries Many classes don’t have virtual functions. Most classes don’t contain __m128 members. Those that have virtual functions often inherit from classes that have virtual functions (interfaces) which avoids the bug. ``` We do NOT mix vc2013 with any other vc++ code

Campbell Barton commented

2014-06-03 10:18:25 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2014-06-03 10:18:25 +02:00

be980b9 & 07e8096 are both using Python3.4, so looks like MSVC2013 is the issue?

be980b9 & 07e8096 are both using Python3.4, so looks like MSVC2013 is the issue?

Martijn Berger commented

2014-06-04 23:31:49 +02:00

It seems to be at least compiler related.

2.70a official and preview show the same regression.

It seems to be at least compiler related. 2.70a official and preview show the same regression.

Campbell Barton changed title from ~~The speed of creating objects~~ to Regression: speed of creating objects (MSVC2013)

2014-06-05 06:40:36 +02:00

Sergey Sharybin commented

2014-06-05 08:27:01 +02:00

Added subscriber: @Sergey

Campbell Barton commented

2014-06-06 15:09:38 +02:00

Its possible this is OpenMP related, since we had reports that OpenMP has speed issues with MSVC2013,

However I tried to compare with/without OpenMP and couldn't notice any speed difference on my system.

Its possible this is OpenMP related, since we had reports that OpenMP has speed issues with MSVC2013, However I tried to compare with/without OpenMP and couldn't notice any speed difference on my system.

Sergey Sharybin commented

2014-06-09 09:29:30 +02:00

Tested with current builds from builder.blender.org and 2.70a release, timing sof the script are the same exact in this two versions. So seems some recent tweaks to OpenMP made things better.

@sant_a, so please grab latest build from builder.b.o and see whether it behaves fine to you.

Tested with current builds from builder.blender.org and 2.70a release, timing sof the script are the same exact in this two versions. So seems some recent tweaks to OpenMP made things better. @sant_a, so please grab latest build from builder.b.o and see whether it behaves fine to you.

Martijn Berger commented

2014-06-09 10:52:29 +02:00

@Sergey I also tested today’s buildbot builds and for me the difference between msvc 2008 and 2013 is insignificant for those builds. ( ~1 %)

What is interesting is just how fast the progressive slowdown of adding more objects happens.

  Cubes 0000 -> 0100 takes  0.56 seconds
  Cubes 0100 -> 0200 takes  0.70 seconds
  Cubes 0200 -> 0300 takes  0.89 seconds
  Cubes 0300 -> 0400 takes  1.15 seconds
  Cubes 0400 -> 0500 takes  1.36 seconds
  Cubes 0500 -> 0600 takes  1.63 seconds
  Cubes 0600 -> 0700 takes  1.85 seconds
  Cubes 0700 -> 0800 takes  2.26 seconds
  Cubes 0800 -> 0900 takes  2.63 seconds
  Cubes 0900 -> 1000 takes  3.12 seconds
  Cubes 1000 -> 1100 takes  3.61 seconds
  Cubes 1100 -> 1200 takes  4.27 seconds
  Cubes 1200 -> 1300 takes  4.92 seconds
  Cubes 1300 -> 1400 takes  5.80 seconds
  Cubes 1400 -> 1500 takes  6.59 seconds
  Cubes 1500 -> 1600 takes  7.57 seconds
  Cubes 1600 -> 1700 takes  8.57 seconds
  Cubes 1700 -> 1800 takes  9.83 seconds
  Cubes 1800 -> 1900 takes 11.09 seconds

@Sergey I also tested today’s buildbot builds and for me the difference between msvc 2008 and 2013 is insignificant for those builds. ( ~1 %) What is interesting is just how fast the progressive slowdown of adding more objects happens. ``` Cubes 0000 -> 0100 takes 0.56 seconds Cubes 0100 -> 0200 takes 0.70 seconds Cubes 0200 -> 0300 takes 0.89 seconds Cubes 0300 -> 0400 takes 1.15 seconds Cubes 0400 -> 0500 takes 1.36 seconds Cubes 0500 -> 0600 takes 1.63 seconds Cubes 0600 -> 0700 takes 1.85 seconds Cubes 0700 -> 0800 takes 2.26 seconds Cubes 0800 -> 0900 takes 2.63 seconds Cubes 0900 -> 1000 takes 3.12 seconds Cubes 1000 -> 1100 takes 3.61 seconds Cubes 1100 -> 1200 takes 4.27 seconds Cubes 1200 -> 1300 takes 4.92 seconds Cubes 1300 -> 1400 takes 5.80 seconds Cubes 1400 -> 1500 takes 6.59 seconds Cubes 1500 -> 1600 takes 7.57 seconds Cubes 1600 -> 1700 takes 8.57 seconds Cubes 1700 -> 1800 takes 9.83 seconds Cubes 1800 -> 1900 takes 11.09 seconds

Sergey Sharybin commented

2014-06-09 11:08:50 +02:00

Added subscriber: @MartijnBerger

Sergey Sharybin commented

2014-06-09 11:08:50 +02:00

@MartijnBerger, this is a known thing. Adding new object is O(N) in blender, adding N objects is more about O(N^2). That's because of ensuring unique ID name and so.. Could be improved, but that's not a thing which is caused by MSVC2013.