wesnoth-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Wesnoth-dev] Improving startup time


From: Yann Dirson
Subject: Re: [Wesnoth-dev] Improving startup time
Date: Fri, 10 Jun 2005 23:34:55 +0200
User-agent: Mutt/1.5.6+20040907i

On Thu, Jun 09, 2005 at 11:37:06PM +0200, Guillaume Melquiond wrote:
> On 6/9/05, Yann Dirson wrote:
> > Here is my patch, which works for me (I have stripped the move to
> > units.cfg for clarity).  Do I have approval for commit ?  Do we want
> > something more sophisticated for 1.0 ?
> 
> The idea is fine with me (in fact I had envisioned the same solution),
> and I think it is worth having in 1.0. And since we are still below
> the 4-define limit, it shouldn't cause any problem. However I wouldn't
> use a CAMPAIGN macro, I would rather have a GAME macro that would be
> defined in all these cases: campaigns, multiplayer and tutorial.

Well, checking twice before committing, I noticed that:

1. campaigns do not get cached, and that the condition in the cache
is...  (defines.size() < 4)

So indeed the limit appears to be 3.  What's the reason ?  If I change
increase the limit by one, things appear to work fine.


2. terrains have to be included at startup, so "load game" can show
the map preview.  Not a big deal.


3. if units are not included at startup, the preview in load dialog,
which shows the leader image, cannot display it either.  This is more
annoying, since units cache is quite big.  This could be worked around
by mentionning the image name in the save files, but it's a quite ugly
solution.  The real fix here may well be to make per-gametime caches
being incremental additions to the main cache, but that'll most
probably be a post-1.0 issue as well :(


With those moves reversed, the cache size is back at 270KB, which is
indeed not a big gain any more, so I guess I won't commit this right
now.


Damn, Dave, are you sure we should not postpone 1.0 a bit :)

Maybe it is time that we create a 1.0 branch intended only for
bugfixing in preparaion for a release, and continue work on the trunk
in parallel.  Then a couple of trunk changes may even be backported to
the 1.0 branch in time for release, once they're ironed out ?

-- 
Yann Dirson    <address@hidden> |
Debian-related: <address@hidden> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]