@Marucs: WHAT ARE YOU TALKING ABOUT!? I AM ALREADY RELAXED!!!$#^(*&@
@Justin: my previous comments were only aimed towards avoiding
premature optimization but now that's another topic. Optimizations
aside, I share your point of view regarding your “first thought”. The
idea is to code using the tools that express the best the intentions
of the developer. If the idea is to have an unique set of elements,
then a set is a good choice.
Still, I'm subjectively happy with my choice of using a comprehensive
list in the context of the `bnn_importFile()` method because it was
the simplest to use. I'm a bit rusty with Python right now, so maybe
I'm wrong, but I believe that if I've had to implement that method
using sets, then I would have had to deal with needless conversions
from/to lists, which would have made the code less readable without
any real improvement on my intentions (I believe it's quite obvious
already, and Marcus proved it)—I'm not even talking here of the
additional allocations that those conversions would have probably
caused on the heap, he he he!
Btw, O(1) does provide better performances than O(n) when processing
but that would be forgetting the initialization-related costs. When
the costs of memory allocation due to a more complex data structure
are significant in comparison to the costs of the operations to
process, then the O(1) algorithm might lose versus the O(n) one in
order of magnitudes. If I remember well, that's what the C++ paper of
vectors vs sets is talking about. That's also why most of the time
there is no universal trick to increase performances and that
benchmarking each snippet of code is the only way to go when required,
and hence why any optimization intuition should be dismissed to focus
solely on the code semantics.
That being said... optimizations look fun! Can't wait to learn how to
dig into assembly code :)
On 2 December 2014 at 17:29, Justin Israel <[email protected]
<mailto:[email protected]>> wrote:
@Marcus, sorry if my suggestion was vague. My intention was that
the list would be that returned from the file import call, when
using the "return new nodes" flag. One could take that list and
query for the assemblies.
@Christopher, while I don't want to further propagate the
off-topic discussion, I figured since we are already there, I
might throw in my 2cents. I actually see valid points in both your
comments as well as Marcus. I definitely agree that premature
optimisation is the root of all evil. But what about cases where a
certain idiom over another could yield a better possible outcome
vs no change at all, simply by it becoming muscle memory? The way
I see it, if you aren't expending any extra time trying to
optimise a piece of code, and your first thought goes to
"membership test in a loop... I'll use a set", did we lose
anything by that? In this particular case, maybe using a set
yields no quantifiable gain, but does the practice in doing so
yield anything over time? Then again, in your defence you are
correct that you did not ask for any help and your code was not
meant to be the subject of evaluation. But either way, it was code
provided, and we tend to spawn conversation on this list at random
points.
Again, I am just throwing in my thoughts on both sides. My own
muscle memory would have made me write a set when looping and
testing membership, at no extra "pre-optimization costs" to my
development process. I just figure O(1) beats O(n) and if I am
wrong, then it is still O(n). But then again no one was asking for
opinions :-)
On Tue, 2 Dec 2014 11:08 PM Christopher Crouzet
<[email protected]
<mailto:[email protected]>> wrote:
I provided my suggestion because I knew that it would meet the
requirements of the question. Why would I need to describe its
code?
I'm not offended, it's just annoying to be linked to some
StackOverflow bullshit like if the answer there was some kind
of holy graal accurately providing a solution for all the
problems in the universe. Even though the author of the answer
rightfully says that “it depends”, and emphasizes on the need
to time it, he still writes as a fact that sets are
significally faster when checking for uniqueness—thus without
any sort of proof. In which case is he right or wrong? Maybe
it becomes true only when using more than 100,000+ elements?
Would the results still be the same for large elements, or
heterogeneous elements? I'd expect from you to be more critic
towards this kind of things.
I'd also expect from you to not give such advices that you
don't know true for sure, especially since I haven't asked any
help on the subject. If I was a newbie, I would believe you as
well as that author on SO, and maybe I would go on rewriting
all my codebase to use sets for such cases and tell all my
friends to do the same, until I'd realize 2 years later how
wrong it all is. All this when *we shouldn't even have been
talking about this matter* for such a non-critical code that
is meant to run once and where *readability prevails*.
It's of course a stupid example but—and you can find some more
literature on the subject—all I'm trying to say here is to be
careful on what you say as it can/will influence others and
might perpetuate bad coding practices.
Enough OT.
On 2 December 2014 at 16:27, Marcus Ottosson
<[email protected] <mailto:[email protected]>> wrote:
Christopher, I’m sorry I didn’t read too carefully through
your code, but you didn’t really provide much information
to along with your suggestion to use your library for the
task in the OP.
and since you seem to enjoy reading development
practices online
I’m sensing I may have offended you, sorry about that.
the number of items being checked for uniqueness
within the list comprehension is most likely to be
very (very) small
My suggestion to use sets here was in regards to comparing
all nodes contained within a file. Files may contain quite
a few nodes, even in the hundreds of thousands, and in
these cases I believe sets produce a noticeable difference.
On 2 December 2014 at 09:08, Christopher Crouzet
<[email protected]
<mailto:[email protected]>> wrote:
I believe you're wrong on both points.
Firstly, the constructor of the iterator
`bnn_MItDagHiearchy
<https://github.com/christophercrouzet/banana.maya/blob/master/banana/maya/extensions/OpenMaya/iterators.py#L214>`
has a default argument `recursive=false`, meaning that
only the top (assembly) DAG nodes will be returned, as
expected by the `bnn_importFile()` method.
Secondly, and since you seem to enjoy reading
development practices online, you must know that you
shouldn't talk about premature optimizations when
there's no actual performance issues. Especially in
this case where:
- the method `bnn_importFile()` most likely won't be
used in a tight loop. And even if it does, the
performance limitations would come from the actual
import of the file incurred by Maya rather than from
something as insignificant as choosing between
list-comprehension or sets.
- the number of items being checked for uniqueness
within the list comprehension is most likely to be
very (very) small, and hence there more likely won't
be any noticeable difference in performances whatever
method is used, even if you decided to generate that
list 17458 times in a row.
On 2 December 2014 at 15:31, Marcus Ottosson
<[email protected]
<mailto:[email protected]>> wrote:
Also as a variation to what Marcus suggested,
instead of needing to first capture the
assemblies in the scene, do the import, and
compare the new assemblies listing to the old
one with a set, you can just pass your list of
nodes to ls() and have it return just the
assemblies.
The question is, which list do you pass? The
reason for doing a before and after is getting the
difference in order to figure out which nodes were
imported, and which were already there.
Using the Maya Python API:
|topLevelDagPaths = list(OpenMaya.bnn_MItDagHierarchy())
OpenMaya.MFileIO.importFile(fileName, type,
preserveReferences,
nameSpace, ignoreVersion)
return [dagPathfor dagPathin
OpenMaya.bnn_MItDagHierarchy()
if not dagPathin topLevelDagPaths]
|
Which seems to iterate using
|OpenMaya.MItDag(OpenMaya.MItDag.kBreadthFirst)|
It looks like this will return /all/ imported
nodes, and not just the assembilies. In addition,
finding differences via list-comprehension is
about 100x slower than using sets.
*
http://stackoverflow.com/questions/2831212/python-sets-vs-lists
On 1 December 2014 at 23:42, Christopher Crouzet
<[email protected]
<mailto:[email protected]>> wrote:
Using the Maya Python API:
https://github.com/christophercrouzet/banana.maya/blob/master/banana/maya/extensions/OpenMaya/MFileIO.py#L19
On 2 December 2014 at 05:54, Justin Israel
<[email protected]
<mailto:[email protected]>> wrote:
Also as a variation to what Marcus
suggested, instead of needing to first
capture the assemblies in the scene, do
the import, and compare the new assemblies
listing to the old one with a set, you can
just pass your list of nodes to ls() and
have it return just the assemblies:
cmds.ls <http://cmds.ls>(nodes,
assemblies=True)
On Tue Dec 02 2014 at 11:05:59 Marcus
Ottosson <[email protected]
<mailto:[email protected]>> wrote:
That's a clever approach!
Along those lines, you could also opt
to import files under a given
namespace; all nodes, including
non-DAG ones, will end up within the
namespace. As a side-note, this is
probably as close as you'll get to the
Softimage "Model".
--
You received this message because you
are subscribed to the Google Groups
"Python Programming for Autodesk Maya"
group.
To unsubscribe from this group and
stop receiving emails from it, send an
email to
[email protected]
<mailto:[email protected]>.
To view this discussion on the web
visit
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOABXtVoG4ruZHg%3DyBMc3oCiRN3mZcoT38J63UcZznj0wA%40mail.gmail.com
<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOABXtVoG4ruZHg%3DyBMc3oCiRN3mZcoT38J63UcZznj0wA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout.
--
You received this message because you are
subscribed to the Google Groups "Python
Programming for Autodesk Maya" group.
To unsubscribe from this group and stop
receiving emails from it, send an email to
[email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3mmgOK4BLFdXZAm_bs7s%2BvfEgyVr-YQkf%2BLPjy%3DM-mYQ%40mail.gmail.com
<https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3mmgOK4BLFdXZAm_bs7s%2BvfEgyVr-YQkf%2BLPjy%3DM-mYQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout.
--
Christopher Crouzet
/http://christophercrouzet.com/
--
You received this message because you are
subscribed to the Google Groups "Python
Programming for Autodesk Maya" group.
To unsubscribe from this group and stop
receiving emails from it, send an email to
[email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CANuKW501RmgWsAnNCj-CWQF2w3%2Bv1owr9KCAwFmaZDsgChs8Jw%40mail.gmail.com
<https://groups.google.com/d/msgid/python_inside_maya/CANuKW501RmgWsAnNCj-CWQF2w3%2Bv1owr9KCAwFmaZDsgChs8Jw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout.
--
*Marcus Ottosson*
[email protected] <mailto:[email protected]>
--
You received this message because you are
subscribed to the Google Groups "Python
Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
[email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAhMU30FaYfqQ1QsOj%3DUdUkuwWWHL8COTp8Tk6em3mDVQ%40mail.gmail.com
<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAhMU30FaYfqQ1QsOj%3DUdUkuwWWHL8COTp8Tk6em3mDVQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout.
--
Christopher Crouzet
/http://christophercrouzet.com/
--
You received this message because you are subscribed
to the Google Groups "Python Programming for Autodesk
Maya" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
[email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CANuKW52KLkM1hMXVqGodK41Yep8gX%3Dd0isoN0r%2BxcQWXSqxLZA%40mail.gmail.com
<https://groups.google.com/d/msgid/python_inside_maya/CANuKW52KLkM1hMXVqGodK41Yep8gX%3Dd0isoN0r%2BxcQWXSqxLZA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout.
--
*Marcus Ottosson*
[email protected] <mailto:[email protected]>
--
You received this message because you are subscribed to
the Google Groups "Python Programming for Autodesk Maya"
group.
To unsubscribe from this group and stop receiving emails
from it, send an email to
[email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODS%2Bj8qweKoSWFTm4Tosbj-MS6SKTZB_ghXU_DPQKS4uQ%40mail.gmail.com
<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODS%2Bj8qweKoSWFTm4Tosbj-MS6SKTZB_ghXU_DPQKS4uQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
Christopher Crouzet
/http://christophercrouzet.com/
--
You received this message because you are subscribed to the
Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to
[email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CANuKW537NmV-dL147iCU%3DnhOOQ3ZGF1hqPngmC91c8okN3%2BoXg%40mail.gmail.com
<https://groups.google.com/d/msgid/python_inside_maya/CANuKW537NmV-dL147iCU%3DnhOOQ3ZGF1hqPngmC91c8okN3%2BoXg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0vFV6CDKofGnNkcwoSY3c4BhRAUakPZy-4rnnBFAKS1w%40mail.gmail.com
<https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0vFV6CDKofGnNkcwoSY3c4BhRAUakPZy-4rnnBFAKS1w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
Christopher Crouzet
/http://christophercrouzet.com/
--
You received this message because you are subscribed to the Google
Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CANuKW53%3Doa9LrxJhcKJZL1zyG%2B08cn1gCUr8SmqZb-a2ZZTVHQ%40mail.gmail.com
<https://groups.google.com/d/msgid/python_inside_maya/CANuKW53%3Doa9LrxJhcKJZL1zyG%2B08cn1gCUr8SmqZb-a2ZZTVHQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
