Reducing Python-Ogre's Size


17-10-2007 01:12:30

Right now the whole thing is pretty huge! It's hard to justify using the library for anything but a local prototype.

Py++ is new to me. It certainly seems to have improved the bindings... but how can the binary be made smaller?

I'm willing to look into it if you have some pointers or advice!



17-10-2007 05:04:41

Which platform are you running on? I assuming its not windows right? I think we can control binary size by proper use of the "private" linkage settings in GCC. They basically remove the all the extra exported symbols from the binaries. That should reduce the size by quite a bit. I also think by default binaries are build with "-g" (at least a while ago I think they were).


17-10-2007 08:33:59

On Linux, the bindings alone are currently 76 Mb! But I'm not so worried bout that platform... Even on Windows, the bindings for the renderer are 18 Mb in the latest release, which is almost 400% bigger than the Ogre code itself!

If it's a Py++ linkage setting, then changes would benefit every platform...

Is there a way to specify more sensible default binding policies? Can Py++ generate Python code where possible like SWIG did?



17-10-2007 15:28:51

Its not a Py++ linkage setting. Its that Py++ does not set any linkage settings at all, so on windows the default it to not export any classes unless you tell it, on Linux its the opposite. Also GCC in general produces large binaries the MSVC.

I am pretty sure that 18MB file on windows compresses pretty good. Besides most games run in the gigabytes these days (even demos are hundreds of megs).

The only way the size is going to go down is if we just wrap less of Ogre, or allow fewer classes to be subclassed. For each overloaded method in those class a new method is generated which calls into python to check to see if the method has been overloaded.


17-10-2007 15:49:17

I think this topic deserves a wiki entry and I'll see about making one this week .

It's interesting that your perception is that the wrapper is too big - so what would be the 'right' size :)

As game_ender points out we wrap absolutely everything AND don't forget we also make any function we can a property AND all the documentation is in the wrapper so pydoc works.

The wrapper won't get significantly smaller unless you wrap less or the compliers get better at template handling (which is what boost is all about) or there is a change with Boost?

So what is the real problem? Do you have a system without enough memory? Or are you in shock about the size :). Yes really using C++ templates does seem to be a beast, however if you want to use Python (and don't want to handcode your wrapper) then it seems a small price to pay.



17-10-2007 18:27:20

There might be a decent argument to make that Py++ could/should generate the Python C code directly, instead of using the Boost.Python template based wrapping system. After all, you are going through all the trouble of generating code, why then have the compiler generated a whole other set of code after that. I think the point of the template based wrapping system was to make it easier to hand write the wrappers.


17-10-2007 23:49:13

Ok, thanks for the clarification guys, that helps a lot.

The reasons I'd like to try to make the library smaller:
  1. Mainly, it's intended to be packaged in a small e-Learning application to be downloaded quickly and painlessly :-)[/*:m]
  2. I'm targeting low-end hardware and don't want it sitting in memory.[/*:m]
  3. I would never use an 18Mb bindings DLL commercially; it's almost the whole memory budget the AI gets on a console![/*:m]
  4. I considered the trade-off for Ogre's 5Mb for a while, so 18Mb for the bindings seems like a bad deal compared to PyOgre.[/*:m][/list:u]
    I will look into removing all the documentation to see how that affects size... I'll also take a peek inside at what's currently bound right now. (I'm increasingly leaning towards a custom API a bit higher-level than Ogre.)

    And for building final builds, it'd be cool to write a script that exposes only what you use in specified .py files :-)

    What do the Py++ people have to say about this? I know the FAQ says something like: be very selective of what to bind for large projects.



18-10-2007 00:54:33

It is definitly possible. Put "custom class wrapping" on the list of features for a the build system upgrade. By that I mean its wholly possible to tell Py++ to not expose certain classes. We just need to find a clean way to integrate it into the system. Of course the real trick would be to figure out which classes you actually use, doing that automatically would be very cool.


18-10-2007 11:36:07

This topic came up before somewhere I'm sure, in fact heres the post: ... ght=packer

seems that UPX will do a good job of compressing the dlls, unless something major has changed :)

disclaimer: I ain't no expert on any of this.... And of course, you're most likely talking about in-memory size, rather than disk size...


in fact i probably ought to shut up really :)