Thread: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing
Brought to you by:
zzzeek
Menu
▾
▴
sqlalchemy-tickets
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 19:21:58
|
#2720: new C extensions for attribute accessing
-------------------------+--------------------------------------------
Reporter: zzzeek | Owner: ged
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Keywords: | Progress State: not decided upon
-------------------------+--------------------------------------------
see attachments
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 20:24:43
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: ged
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by zzzeek):
Running this against 0.8, only one of the aaa_profiling tests falls out of
range here. Here's a summary of most of the ORM related profiling tests.
The orm_2010.py script has the best savings as it works with a large
number of objects. Overall these savings aren't too dramatic.
{{{
C extension, test_orm
Pstats calls: 16991
Pstats calls: 113793
Pstats calls: 19165
Pstats calls: 1190
Pstats calls: 122
Pstats calls: 18
no C extension, test_orm
Pstats calls: 17987
Pstats calls: 114819
Pstats calls: 19165
Pstats calls: 1190
Pstats calls: 122
Pstats calls: 18
C extension, zoomark_orm:
Pstats calls: 6140
Pstats calls: 390
Pstats calls: 6389
Pstats calls: 19003
Pstats calls: 1049
Pstats calls: 2671
no C extension: zoomark ORM
Pstats calls: 6104
Pstats calls: 390
Pstats calls: 6397
Pstats calls: 19024
Pstats calls: 1049
Pstats calls: 2668
C extension, orm_2010.py
Total calls 4055180
Total cpu seconds: 4.41
Total execute calls: 11201
Total executemany calls: 101
no C extension, orm_2010.py
Total calls 4137179
Total cpu seconds: 4.46
Total execute calls: 11201
Total executemany calls: 101
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 20:26:46
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Changes (by zzzeek):
* owner: ged => zzzeek
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 20:27:09
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Changes (by zzzeek):
* cc: klaussfreire@… (added)
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 20:38:11
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
Is "no C extension" '''no''' extension at all, or just no patch?
If it's no extension at all, it makes difficult to compare. I also don't
know about the test's representativeness. It doesn't seem to do much with
the objects, just fetch them.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 20:42:23
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by zzzeek):
"no C extension" means I removed the file "cinstrumented.so" alone, so the
other C extensions remained in place.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:5>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 20:43:04
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by zzzeek):
so yes, what would be good here would be a test like orm2010.py that has a
heavy emphasis on attribute access. orm2010.py is heavy on the
persistence side, though persistence makes a lot of use of getters too.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:6>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 21:39:54
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
Um... I've been having trouble reproducing the function call excess
problem with test_orm, and I noticed it doesn't use declarative, so only
relationships use instrumented attributes.
However, when using declarative, even basic columns do.
So, I guess what's needed here is a test using declarative. Is orm_2010
that? I can't find it in test/aaa_profiling...
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:7>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 22:44:35
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by zzzeek):
using declarative vs. mapper() has no effect on how columns are ultimately
mapped. If the table has a column ".id", it is instrumented in the same
way whether or not declarative is used.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:8>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 22:53:56
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
Then I'm running the tests the wrong way...
I mess or restore ./build/lib.blah/sqlalchemy/cinstrumented.so and run
./sqla_nose.py test.aaa_profiling.test_orm or python
./test/perf/orm2010.py
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:9>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 22:55:51
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
Oh... I know... I have cinstrumented installed in python, if it's not
there it loads it from /usr/local...
I'll have to build a virtualenv.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:10>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-06 23:30:14
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
Alright, virtualenv in place,
Unpached (no cinstrumented):
{{{
(env)claudiofreire@klaumpp:~/src/SQLAlchemy-0.8.1>
PYTHONPATH=$(pwd)/build/lib.linux-x86_64-2.7/ python
test/perf/orm2010read.py
/home/claudiofreire/src/SQLAlchemy-0.8.1/build/lib.linux-
x86_64-2.7/sqlalchemy/types.py:307: SAWarning: Dialect sqlite+pysqlite
does *not* support Decimal objects natively, and SQLAlchemy must convert
from floating point - rounding errors and other issues may occur. Please
consider storing Decimal numbers as strings or integers on this platform
for lossless storage.
d[coltype] = rp = d['impl'].result_processor(dialect, coltype)
SQLA Version: 0.8.1
Total calls 706284
Total cpu seconds: 1.94
Total execute calls: 101
Total executemany calls: 0
sh: runsnake: command not found
}}}
Patched (with cinstrumented):
{{{
(env)claudiofreire@klaumpp:~/src/SQLAlchemy-0.8.1>
PYTHONPATH=$(pwd)/build/lib.linux-x86_64-2.7/ python
test/perf/orm2010read.py
/home/claudiofreire/src/SQLAlchemy-0.8.1/build/lib.linux-
x86_64-2.7/sqlalchemy/types.py:307: SAWarning: Dialect sqlite+pysqlite
does *not* support Decimal objects natively, and SQLAlchemy must convert
from floating point - rounding errors and other issues may occur. Please
consider storing Decimal numbers as strings or integers on this platform
for lossless storage.
d[coltype] = rp = d['impl'].result_processor(dialect, coltype)
SQLA Version: 0.8.1
Total calls 646370
Total cpu seconds: 1.69
Total execute calls: 101
Total executemany calls: 0
sh: runsnake: command not found
}}}
Will attach orm2010read.py, with emphasis on read-only stuff.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:11>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-08 01:09:57
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by zzzeek):
OK...can you tell me about this:
{{{
basic_dict = PyObject_GetAttrString(instance, "__dict__");
142 if (basic_dict == NULL) {
143 /* No problem, we'll fall back to the generic
implementation anyway */
144 PyErr_Clear();
145 }
}}}
what it seems like we're doing here, is seeing if `__dict__` is there, and
if so, then great we can skip using `instance_dict()`. That's not
actually how `instance_dict()` is supposed to work - it's supposed to be
consulted unconditionally. The whole `instance_dict()` thing is really
unfortunate in that I think there is exactly one application on the planet
that actually needs it to access something other than `__dict__`, but the
fact is that in the default case it is actually an `attrgetter` for
`__dict__` and should be extremely fast. Am I correct about that step
and can that be removed, hopefully simplifying the code ? Overall it's
a little weird that we're replacing literally six lines of Python code
with 426 lines of C.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:12>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-08 01:23:04
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
No, it's not that at all. What it's doing, is try to get the __dict__, for
comparison against the instance_dict() return value. Caching (which is
what accelerates things) is only enabled when:
{{{instance_dict(instance) is instance.__dict__}}}
and
{{{self.impl.get(instance_state(instance), dict_)}}} is successful (ie: no
errors).
If both happen, then from that point onwards, all attribute accesses of
that kind (ie: {{{Entity.id}}} for all instances of Entity) will shortcut
directly towards {{{instance.__dict__[self.key]}}}, as long as
{{{globals()['instance_dict']}}} hasn't changed.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:13>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-08 02:47:54
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by zzzeek):
so the speed savings are:
1. the comparison of `self->cached_instance_dict == instance_dict ` and
such are straight C references, so this is extremely fast, then
2. `rv = PyObject_GetItem(basic_dict, key);` allows us to quickly get a
value or NULL without the overhead of either "key in dict" or catching an
expensive `KeyError`
is that right?
also did you run any regular timeit's? I'm assuming we'd see similar
percentages.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:14>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-08 03:07:13
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
Right. Well, {{{key in dict_}}} then {{{return dict_[key]}}} does the
lookup twice, and catching the !KeyError has to set up a try/catch block,
which is what is expensive about it (kinda like a stack bookmark CPython's
VM can roll back to).
But the real savings here come from:
* {{{Entity.id}}} goes from CPython's VM (LOAD_ATTR) directly towards the
C code, there's no frame setup or bytecodes involved (that's why the call
doesn't show up in profiles). With these ultra-cheap functions, frame
setup can be 90% of the cost.
* {{{PyBlah_Bleh}}} calls are all native. While, true, not immensely
quicker than equivalent VM bytecodes, the fact that they're just working
with simple dict ops and non-property attributes makes the VM itself a
hinderance. {{{Entity.id}}} was about a dozen opcodes, that's a dozen
loops over a huge switch block that interprets the bytecode. Now it's a
pair of native calls. That's '''way''' faster in comparison.
While those two wouldn't normally matter much in the overall picture, the
fact that properly optimized CPU-bound SQLAlchemy apps tend to be all
about reading attributes (in my experience), changes things.
I didn't try the timeit. I will as soon as I get back to my SA devel
machine (ie: the office).
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:15>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-08 03:11:21
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
BTW: Hold on a bit if 426 lines of C look intimidating (I'd think so),
since I still have to try Pyrex. I've got to check whether Pyrex can
replace the other extensions too, for it would be pointless to just
introduce it for this one and not the others.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:16>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-08 14:58:55
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
Ok, timeit.
This is the test:
{{{
>>> def test():
... for _ in xrange(10):
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
... _ = rc.hash
...
}}}
Yeah, I did it on the console, and yeah, I made sure both runs contained
the same number of rc.hash lines.
With cinstrumented:
{{{
>>> timeit.timeit(test)
156.2858281135559
}}}
Without cinstrumented:
{{{
>>> timeit.timeit(test)
188.22997498512268
}}}
Unsurprising.
PS: I did not include a query in the timeit function because I'm working
with a remote DB ATM, and it'd overshadow attribute access. I don't have a
local db handy.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:17>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-08 15:05:43
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by ged):
Replying to [comment:16 claudiofreire]:
> BTW: Hold on a bit if 426 lines of C look intimidating (I'd think so),
since I still have to try Pyrex. I've got to check whether Pyrex can
replace the other extensions too, for it would be pointless to just
introduce it for this one and not the others.
FWIW, I discovered Cython just after I finished implementing the initial C
extensions (but before it got committed), so I did try to generate them
using Cython. Back then, I could not get Cython (never tried pyrex) code
to be nearly as fast as the pure C extensions, so I dropped the idea since
the pure C extensions were already written. It was faster than pure-python
but not fast enough (IMO) to be worth it. It is certainly worth it to try
that again, as if the speed improvement is close enough to the pure C
extensions, Cython code is indeed much more maintainable.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:18>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-05-08 15:21:18
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
Well, it certainly is tricky to get optimal performance, but I've never
failed achieving C speeds with Pyrex. I know Cython tries to do type
inference to speed up things, in Pyrex you have to annotate types. I've
found explicit annotation is more predictable than relying on type
inference, that's why I prefer Pyrex. I just need careful cdefs and
everything flies.
When there is a need for native C code, you can always include C code from
Pyrex. I've in fact done that to include C++ code, when C++'s template
power was required. The benefit over pure C extensions is that you avoid
all that CPython boilerplate.
So it's a matter of how much needs to be pure C and how much can Pyrex
replace, I don't think it will make a difference in speed (ie: it will be
just as fast).
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:19>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-01 20:54:21
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
So, I finally got back to this. Pyrex has no Py3 support, so Cython's the
only choice.
cprocessors.int_to_bool becomes a tad slower, going from 0.84s (py2) to
0.94s (py3) for 10M iterations. Is that in line with your previous
results?
The same code with cython and py2 stays at 0.84s, so I'm wondering if the
slowness is a py3 thing instead of a cython thing.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:20>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-31 16:32:39
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: blue sky
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Changes (by zzzeek):
* milestone: 0.9.0 => blue sky
Comment:
this issue seems to be dead for now, tabling out to blue sky.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:21>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-31 16:43:57
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: blue sky
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
Ehm... without an answer to the above?
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:22>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-31 16:46:56
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: blue sky
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by zzzeek):
Whats the question? how long does 10M iterations of int_to_bool take on
my system? how would that be of use without something to compare it to on
the identical system ?
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:23>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-31 16:48:01
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: blue sky
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
No, it had been said that at some point someone tried Cython, and the
performance hit was unacceptable. The question was whether the performance
hit mentioned above was equally unacceptable.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:24>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
