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.!!!

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?

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.

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 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

rBbe980b9 & rB07e8096 are both using Python3.4, so looks like MSVC2013 is the issue?

It seems to be at least compiler related.

2.70a official and preview show the same regression.

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.

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.

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

@Sergey Sharybin (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

@Martijn Berger (juicyfruit), 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.

The speed of object creation in the release e8c63ca really no worse than 2.70a. Thanks Sergey. The issue has been resolved.