[Python-Dev] 2.0 Optimization & speed
M.-A. Lemburg
mal@lemburg.com
Fri, 08 Sep 2000 22:53:32 +0200
Vladimir Marangozov wrote:
>
> M.-A. Lemburg wrote:
> >
> > Fredrik Lundh wrote:
> > >
> > > mal wrote:
> > > > > - compact the unicodedata database, which is expected to reduce the
> > > > > mem footprint, maybe improve startup time, etc. (ongoing)
> > > >
> > > > This was postponed to 2.1. It doesn't have any impact on
> > > > performance...
> > >
> > > sure has, for anyone distributing python applications. we're
> > > talking more than 1 meg of extra binary bloat (over 2.5 megs
> > > of extra source code...)
> >
> > Yes, but not there's no impact on speed and that's what Valdimir
> > was referring to.
>
> Hey Marc-Andre, what encoding are you using for printing my name? <wink>
Yeah, I know... the codec swaps character on an irregular basis
-- gotta fix that ;-)
> >
> > > the 2.0 release PEP says:
> > >
> > > Compression of Unicode database - Fredrik Lundh
> > > SF Patch 100899
> > > At least for 2.0b1. May be included in 2.0 as a bug fix.
> > >
> > > (the API is frozen, and we have an extensive test suite...)
> >
> > Note that I want to redesign the Unicode database and ctype
> > access for 2.1: all databases should be accessible through
> > the unicodedatabase module which will be rewritten as Python
> > module.
> >
> > The real data will then go into auxilliary C modules
> > as static C data which are managed by the Python module
> > and loaded on demand. This means that what now is unicodedatabase
> > will then move into some _unicodedb module.
>
> Hey Marc-Andre, don't try to reduce /F's crunching efforts to dust.
Oh, I didn't try to reduce Fredrik's efforts at all. To the
contrary: I'm still looking forward to his melted down version
of the database and the ctype tables.
The point I wanted to make was that all this can well be
done for 2.1. There are many more urgent things which need
to get settled in the beta cycle. Size optimizations are
not necessarily one of them, IMHO.
> My argument doesn't hold, but Fredrik has a point and I don't see how
> your future changes would invalidate these efforts. If the size of
> the distribution can be reduced, it should be reduced! Did you know
> that telecom companies measure the quality of their technologies on
> a per bit basis? <0.1 wink> Every bit costs money, and that's why
> Van Jacobson packet-header compression has been invented and is
> massively used. Whole armies of researchers are currently trying to
> compensate the irresponsible bloatware that people of the higher
> layers are imposing on them <wink>. Careful!
True, but why the hurry ?
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/