I just upgraded from wxpython 2.6.3.3 to 2.8.1.1
(Using Windows XP, Python 2.4.4)
After doing so, the size of my executable (built with
py2exe) grew almost 8%.
Closer inspection showed the following changes between
2.6.3.3 and 2.8.1.1:
2.6.3.3
···
=======
_controls_.pyd 600k
_core_.pyd 672k
_gdi_.pyd 368k
_windows_.pyd 532k
_misc_.pyd 484k
library.zip (contains all the pyc's) 5887k
2.8.1.1
_controls_.pyd 884k
_core_.pyd 904k
_gdi_.pyd 704k
_windows_.pyd 632k
_misc_.pyd 644k
library.zip (contains all the pyc's) 6132k
The difference is 1350k and the only thing that
changed was the wxpython upgrade.
It is important to prevent my app from growing much
more. I've already gone through the exercise of
eliminating any unnecesary imports in my code.
Is there anything I can do to reduce the amount of
bloating that occurs with each upgrade?
If not, can anything be done in future releases of
wxpython such as modularizing the above pyd's so that
if certain classes of code are not being used then
they won't be pulled into the build?
Thanks,
Jeremy.
____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
I am unclear about why the wx and core modules are named "_wx.py" and
"_core.py". What is the purpose of the underscores? How can "import wx"
work when the module is really named with an underscore?
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
It's actually a bit worse than that. With wxPython 2.8, you need to
include gdiplus.dll (for wxPython) and perhaps even msvcrt71.dll (for
Python 2.4/2.5) to make sure that your executable will run on all
Windows machines. With wxPython 2.6, you could use Python 2.3, which
didn't have the need for msvcrt71.dll .
Generally speaking, about the only thing you can really do to reduce the
size of your distributions is to include the zlib library in Python 2.4
and prior, and make sure to recompress the library.zip (there is an
option to pass to py2exe to do this for you). In wxPython 2.6
distributions, I usually get around 1 meg for the .pycs (I haven't
switched to wxPython 2.8 for similar reasons, but primarily because _I_
still need to use Python 2.3).
- Josiah
···
jeremy alexander <jccfifkf@yahoo.com> wrote:
I just upgraded from wxpython 2.6.3.3 to 2.8.1.1
(Using Windows XP, Python 2.4.4)
After doing so, the size of my executable (built with
py2exe) grew almost 8%.
Closer inspection showed the following changes between
2.6.3.3 and 2.8.1.1:
When you “import wx”, you’re not actually importing _wx.py (or _core.py); you’re importing the “wx” package (directory) which has a whole bunch of files within. Specifically, it has the init.py inside it that handles baasic initialization of wxPython.
It, among other things, imports all the contents of _core.py into the “wx” namespace.
Why have the underscore? So you don’t ever touch/import it directly I’d assume-- since its contents are now stored in the “wx” namespace.
I am unclear about why the wx and core modules are named "_wx.py" and
"_core.py". What is the purpose of the underscores? How can "import wx"
work when the module is really named with an underscore?
It's the magic of packages. The file that does much of the work for
wxPython is actually wx/__init__.py . See the "Packages" section in the
tutorial: http://docs.python.org/tut/node8.html
You can reduce the size of wxPython considerably if you build
wxWidgets and wxPython yourself with appropriate changes to setup.h.
The pyds you list above are all "core" to wxPython. The stuff that
isn't is in wx.lib.
You might also re-think the need to upgrade wxPython versions - if you
don't need new functionality, there is little incentive to upgrade and
get the size increases the new functionality brings.
···
On 2/18/07, jeremy alexander <jccfifkf@yahoo.com> wrote:
Hi,
I just upgraded from wxpython 2.6.3.3 to 2.8.1.1
(Using Windows XP, Python 2.4.4)
After doing so, the size of my executable (built with
py2exe) grew almost 8%.
Closer inspection showed the following changes between
2.6.3.3 and 2.8.1.1:
2.6.3.3
_controls_.pyd 600k
_core_.pyd 672k
_gdi_.pyd 368k
_windows_.pyd 532k
_misc_.pyd 484k
library.zip (contains all the pyc's) 5887k
2.8.1.1
_controls_.pyd 884k
_core_.pyd 904k
_gdi_.pyd 704k
_windows_.pyd 632k
_misc_.pyd 644k
library.zip (contains all the pyc's) 6132k
The difference is 1350k and the only thing that
changed was the wxpython upgrade.
It is important to prevent my app from growing much
more. I've already gone through the exercise of
eliminating any unnecesary imports in my code.
Is there anything I can do to reduce the amount of
bloating that occurs with each upgrade?
If not, can anything be done in future releases of
wxpython such as modularizing the above pyd's so that
if certain classes of code are not being used then
they won't be pulled into the build?
Have you looked at http://wiki.wxpython.org/index.cgi/DistributingYourApplication? Using UPX you can greatly reduce the size of those. I tried this out for our application and reduced the size from 35 megs to 18. This seemed to consistently halve the sizes of dlls and pyds.
I just upgraded from wxpython 2.6.3.3 to 2.8.1.1
(Using Windows XP, Python 2.4.4)
After doing so, the size of my executable (built with
py2exe) grew almost 8%.
Closer inspection showed the following changes between
2.6.3.3 and 2.8.1.1:
2.6.3.3
_controls_.pyd 600k
_core_.pyd 672k
_gdi_.pyd 368k
_windows_.pyd 532k
_misc_.pyd 484k
library.zip (contains all the pyc's) 5887k
2.8.1.1
_controls_.pyd 884k
_core_.pyd 904k
_gdi_.pyd 704k
_windows_.pyd 632k
_misc_.pyd 644k
library.zip (contains all the pyc's) 6132k
The difference is 1350k and the only thing that
changed was the wxpython upgrade.
It is important to prevent my app from growing much
more. I've already gone through the exercise of
eliminating any unnecesary imports in my code.
Is there anything I can do to reduce the amount of
bloating that occurs with each upgrade?
If not, can anything be done in future releases of
wxpython such as modularizing the above pyd's so that
if certain classes of code are not being used then
they won't be pulled into the build?
Thanks,
Jeremy.
____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
It's actually a bit worse than that. With wxPython 2.8, you need to
include gdiplus.dll (for wxPython) and perhaps even msvcrt71.dll (for
Python 2.4/2.5) to make sure that your executable will run on all
Windows machines. With wxPython 2.6, you could use Python 2.3, which
didn't have the need for msvcrt71.dll .
Generally speaking, about the only thing you can really do to reduce the
size of your distributions is to include the zlib library in Python 2.4
and prior, and make sure to recompress the library.zip (there is an
option to pass to py2exe to do this for you). In wxPython 2.6
distributions, I usually get around 1 meg for the .pycs (I haven't
switched to wxPython 2.8 for similar reasons, but primarily because _I_
still need to use Python 2.3).
- Josiah
If the size of the exe is a serious consideration, there is another choice: use PyInstaller (http://pyinstaller.python-hosting.com/). I've moved to it for most of my apps, which have shrunk in size from about 13-14Mb to around 4-5Mb. (This is for single-file apps; you can build single-folder as well.) Another advantage: it folds the msvcrt DLLs into the file, so you don't have to distribute them separately. Also, there's portability: it works on Linux, and Mac support is in the works.
The downsides: first, of course, the cost of familiarizing yourself with it -- its spec files are definitely different than py2exe's setup files. (I found the documentation somewhat better than py2exe's, but it still takes some careful reading and experimentation.) Also, there's a slight delay when starting an app; the first thing that happens is the decompression of the exe into a set of files in a temp directory that provides the execution environment, then your main program gets called (on exit, the files are cleaned up). I haven't found that to be a problem, but if you really need almost instant startup, it could be a showstopper.
It is important to prevent my app from growing much
more. I've already gone through the exercise of eliminating any unnecesary imports in my code.
Is there anything I can do to reduce the amount of
bloating that occurs with each upgrade?
You can build a custom version of wxWidgets and wxPython that excludes the classes you don't need.
If not, can anything be done in future releases of
wxpython such as modularizing the above pyd's so that
if certain classes of code are not being used then
they won't be pulled into the build?
The modules you listed are all part of the core wx namespace, IOW what you get when you "import wx". If any of the classes are factored out into other modules, then they will either need to still be imported in wx.__init__ to preserve compatibility, or they will cause existing code using them to break as you'll have to do something like "import wx.tree" to get access to the TreeCtrl class.
I have thought in the past about using some sort of import-on-demand scheme, but I expect that will just add more complexity than it is worth.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
When you "import wx", you're not actually importing _wx.py (or _core.py); you're importing the "wx" package (directory) which has a whole bunch of files within. Specifically, it has the __init__.py inside it that handles baasic initialization of wxPython.
It, among other things, imports all the contents of _core.py into the "wx" namespace.
Why have the underscore? So you don't ever touch/import it directly I'd assume-- since its contents are now stored in the "wx" namespace.
Correct. I just used it as a hint that these modules shouldn't be used directly.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I am still having this problem ....any ideas? Thanks....
[root@seattle ~]# python
Python 2.5 (r25:51908, Feb 18 2007, 02:11:58)
[GCC 3.4.3 20050227 (Red Hat 3.4.3-22.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import wx
__main__:1: DeprecationWarning: The wxPython compatibility package is no
longer automatically generated or activly maintained. Please switch to
the wx package as soon as possible.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.5/site-packages/wx/__init__.py", line 15,
in <module>
import _wx
File "/usr/local/lib/python2.5/site-packages/wx/_wx.py", line 3, in
<module>
from _core import *
File "/usr/local/lib/python2.5/site-packages/wx/_core.py", line 22, in
<module>
wxNOT_FOUND = wx._core.NOT_FOUND
AttributeError: 'module' object has no attribute '_core'
···
I am unclear about why the wx and core modules are named "_wx.py" and
"_core.py". What is the purpose of the underscores? How can "import wx"
work when the module is really named with an underscore?
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
Just out of curiosity. How small can a custom version of wxPython get if the only functionality needed is just enough to display a frame, OnPaint handling (with new GCDC) and mouse movement/clicking plus keyboard input.
I don’t need an exact figure… just an educated guess.
I am still having this problem ....any ideas? Thanks....
[root@seattle ~]# python
Python 2.5 (r25:51908, Feb 18 2007, 02:11:58)
[GCC 3.4.3 20050227 (Red Hat 3.4.3-22.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import wx
__main__:1: DeprecationWarning: The wxPython compatibility package is no
longer automatically generated or activly maintained. Please switch to
the wx package as soon as possible.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.5/site-packages/wx/__init__.py", line 15,
in <module>
import _wx
File "/usr/local/lib/python2.5/site-packages/wx/_wx.py", line 3, in
<module>
from _core import *
File "/usr/local/lib/python2.5/site-packages/wx/_core.py", line 22, in
<module>
wxNOT_FOUND = wx._core.NOT_FOUND
AttributeError: 'module' object has no attribute '_core'
It looks to me like your wxPython package and wx package have gotten merged somehow. There should be no "import _wx" in wx/__init__.py, and this is the source of the problems further down the stack. Another clue is the DeprecationWarning, it should only be raised if you "import wxPython" not "import wx"
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
On 2/19/07, *Robin Dunn* <robin@alldunn.com <mailto:robin@alldunn.com>> > wrote:
I have thought in the past about using some sort of import-on-demand
scheme, but I expect that will just add more complexity than it is
worth.
Just out of curiosity. How small can a custom version of wxPython get if the only functionality needed is just enough to display a frame, OnPaint handling (with new GCDC) and mouse movement/clicking plus keyboard input.
I don't need an exact figure... just an educated guess.
An "educated guess" implies that there is experience or training upon which to base a theoretical hypothesis. But since I have no experience in this all I can give is a SWAG and say 1/3 to 1/2 of the current size for the .pyd/.so files.
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I forgot to mention that I wrap the package from
py2exe with the Inno Setup Installer (ISI) to produce
the final setup.exe file. ISI compresses the entire
package using lzma.
I followed the various suggestions (thanks by the
way!) that were given regarding using UPX on the
executable files and compressing the library.zip file
with 7zip. After lots of experimenting I found that I
could never produce a smaller setup.exe than if I
just used the ISI compressor. The results are
summarized below:
ISSCompression 7zLibrary.zip UPX Result
···
================================================
1) Off On On Larger
2) Off On Off Larger
3) Off Off On Larger
4) On On Off Larger
5) On Off On Larger
6) On On On Larger
7) On Off Off Best
The first 6 results were all larger than the best
result. Also found that just UPXing one medium sized
executable and then compressing the remainder with the
Inno compressor still results in a larger setup.exe.
To give you an idea of the kind of numbers involved,
if everything is uncompressed, the total size of the
app is 19M. After compression with ISI, the total
size of the setup.exe is 4.6M. All the variations
shown in the table above resulted in sizes from 4.8M
to 7.4M.
The only advantage to tightly compressing the
library.zip and using UPX is that when the package is
installed in a user folder, the size of the folder is
much smaller than if you dont precompress any files
or the library.zip.
But what I am after is to control and if possible
reduce the size of the setup.exe. The reason is that
setup files for comparable programs are already much
smaller. The larger my app becomes, the more at a
disadvantage it would be against the smaller programs.
There was one suggestion to try using pyInstaller
instead of py2exe. I didnt have time to try that yet
but will look into it in the future.
One tip I found useful was to run py2exe with the OO
option. This resulted in a slightly smaller
setup.exe. I also ran UPX on the final setup.exe file
and got a slight compression
Jeremy.
--- Josiah Carlson <jcarlson@uci.edu> wrote:
jeremy alexander <jccfifkf@yahoo.com> wrote:
> I just upgraded from wxpython 2.6.3.3 to 2.8.1.1
> (Using Windows XP, Python 2.4.4)
>
> After doing so, the size of my executable (built
with
> py2exe) grew almost 8%.
> Closer inspection showed the following changes
between
> 2.6.3.3 and 2.8.1.1:
[snip]
It's actually a bit worse than that. With wxPython
2.8, you need to
include gdiplus.dll (for wxPython) and perhaps even
msvcrt71.dll (for
Python 2.4/2.5) to make sure that your executable
will run on all
Windows machines. With wxPython 2.6, you could use
Python 2.3, which
didn't have the need for msvcrt71.dll .
Generally speaking, about the only thing you can
really do to reduce the
size of your distributions is to include the zlib
library in Python 2.4
and prior, and make sure to recompress the
library.zip (there is an
option to pass to py2exe to do this for you). In
wxPython 2.6
distributions, I usually get around 1 meg for the
.pycs (I haven't
switched to wxPython 2.8 for similar reasons, but
primarily because _I_
still need to use Python 2.3).
- Josiah
____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
> It is important to prevent my app from growing
much
> more. I've already gone through the exercise of
> eliminating any unnecesary imports in my code.
> Is there anything I can do to reduce the amount of
> bloating that occurs with each upgrade?
You can build a custom version of wxWidgets and
wxPython that excludes
the classes you don't need.
I'd be game to try this approach but I've never
done it before. Are there any detailed instructions
available on how to go about doing this?
>
> If not, can anything be done in future releases of
> wxpython such as modularizing the above pyd's so
that
> if certain classes of code are not being used then
> they won't be pulled into the build?
The modules you listed are all part of the core wx
namespace, IOW what
you get when you "import wx". If any of the classes
are factored out
into other modules, then they will either need to
still be imported in
wx.__init__ to preserve compatibility, or they will
cause existing code
using them to break as you'll have to do something
like "import wx.tree"
to get access to the TreeCtrl class.
I have thought in the past about using some sort of
import-on-demand
scheme, but I expect that will just add more
complexity than it is worth.
What if major classes were factored out into
their own modules and the modules were all imported
into wx.__init__. The wxpython package would then be
functionally equivalent to what it is now.
But people like me who are concerned about the size of
their applications would then be able to comment out
the unnecessary imports.
Would that work?
Jeremy
···
--- Robin Dunn <robin@alldunn.com> wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax
with wxPython!
To unsubscribe, e-mail:
wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time
with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
more. I've already gone through the exercise of eliminating any unnecesary imports in my code.
Is there anything I can do to reduce the amount of
bloating that occurs with each upgrade?
You can build a custom version of wxWidgets and
wxPython that excludes the classes you don't need.
> I'd be game to try this approach but I've never
done it before. Are there any detailed instructions
available on how to go about doing this?
Not really. You'll basically need to follow the regular build instructions. On Windows you control what is built or not built in wxWidgets by editing the include/wx/msw/setup.h file, and then rebuilding all of wxWidgets. In wxPython it will take more work because for the most part it assumes that all of standard wxWidgets is available, so you'll need to either remove or comment-out the class definitions in the *.i files that you are disabling in the wxWidgets build, and then rerun SWIG and then rebuild wxPython as described in the regular build instructions.
> > What if major classes were factored out into
their own modules and the modules were all imported
into wx.__init__. The wxpython package would then be
functionally equivalent to what it is now. But people like me who are concerned about the size of
their applications would then be able to comment out
the unnecessary imports. Would that work?
It could, however there would be some additional overhead per module (runtime and also disk space) and perhaps some additional complexities for the build.
···
--- Robin Dunn <robin@alldunn.com> wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
