slow startup speed, XP SP 3
pete m
3.0 is atrocious, and it doesn't just apply to V. The same applies to
NPP5beta4: it takes several minutes for the app to give the splash
screen. Does anyone have any clue what's going on? Unfortunately,
I don't have a decent IDE to figure it out with, nor do I have enough
windows internals programming experience.
zai...@zaimoni.com
> I've seen the same complaint vis a vis Vista--the startup speed on SP
> 3.0 is atrocious, and it doesn't just apply to V. The same applies to
> NPP5beta4: it takes several minutes for the app to give the splash
> screen. Does anyone have any clue what's going on?
I get a factor of 5 speedup from the win-main.c efficient font patch,
but it needs tweaking to avoid a rendering backfire from some changes
since V3.0.6. I won't be able to get on it until at least Sept 1st
2008.
Timo Pietilä
It is Vista, what did you expect? Vista is slow by design.
Timo Pietilä
ShieTar
I think he wanted to say that XP SP 3 is slower than Vista?
Anyway, something similar: Yesterday I installed Angband once again
(3.0.9b) and since the last time I played I've got a new Graphics Card
(HD 3850) and the above-mentioned Service Pack. Now if I try to play
with tiles (either set), the screen update is extremely slow, takes more
than a second. So I'm not sure if it is the Graphicscard (ATI instead of
NVIDIA?) or SP3.
Installed AngbandTk, no problems there.
Klaus Kruse
Timo Pietilä
> Timo Pietilä wrote:
>> pete m wrote:
>>> I've seen the same complaint vis a vis Vista--the startup speed on SP
>>> 3.0 is atrocious, and it doesn't just apply to V. The same applies to
>>> NPP5beta4: it takes several minutes for the app to give the splash
>>> screen. Does anyone have any clue what's going on? Unfortunately,
>>> I don't have a decent IDE to figure it out with, nor do I have enough
>>> windows internals programming experience.
>>
>> It is Vista, what did you expect? Vista is slow by design.
>>
>> Timo Pietilä
>
> I think he wanted to say that XP SP 3 is slower than Vista?
I certainly didn't, and I don't think Pete did either. Vista is slower
than XP by all possible tests.
> Anyway, something similar: Yesterday I installed Angband once again
> (3.0.9b) and since the last time I played I've got a new Graphics Card
> (HD 3850) and the above-mentioned Service Pack. Now if I try to play
> with tiles (either set), the screen update is extremely slow, takes more
> than a second. So I'm not sure if it is the Graphicscard (ATI instead of
> NVIDIA?) or SP3.
Angband is so small that it can't be modern computer resources that
causes slowdown. It must be some buggy program. Either graphics card
driver is buggy, fonts are buggy or something is wrong in angband native
windows compile.
Timo Pietilä
ShieTar
Funny enough, I just found out that the reason was my CPU power saving
managment. If I disable the lowest throttling level (800 MHz) Angband
works as smooth as I expect it to. Even though the CPU load never got
very high, even when set to 800 MHz frequency. And I'm pretty sure it
should run just fine on a real 800 MHz CPU. Maybe some other
power-saving state is the reason.
Klaus Kruse
zai...@zaimoni.com
> Funny enough, I just found out that the reason was my CPU power saving
> managment. If I disable the lowest throttling level (800 MHz) Angband
> works as smooth as I expect it to. Even though the CPU load never got
> very high, even when set to 800 MHz frequency. And I'm pretty sure it
> should run just fine on a real 800 MHz CPU. Maybe some other
> power-saving state is the reason.
I had to disable *all* power-saving on Vista to make the broadband
connection work reliably; it wouldn't surprise me that V wasn't using
enough CPU and thus got starved even more.
That wasn't enough to get a reasonable launch time for V SVN; it's
still at ~15 seconds on my Vista system (2.2GHz, hardware DEP enabled
for all applications). Zaiband was taking as long before I put in the
efficient fonts patch, but lag time is still between 1-2 seconds with
efficient fonts.
red_...@hotmail.com
death or otherwise ;).
The reason though isn't (for the most part) the OS (Two XP sp3, a XP
sp2 and a Vista sp1) but rather the fact I use a terribly slow
(writing) USB key to store angband on and I've monitered the files
accesses using procmon: the INI file writing code seems to be total
crap since it opens, reads, writes, closes the file tons of times
(which is where my USB slows down).
zai...@zaimoni.com
> The reason though isn't (for the most part) the OS (Two XP sp3, a XP
> sp2 and a Vista sp1) but rather the fact I use a terribly slow
> (writing) USB key to store angband on and I've monitered the files
> accesses using procmon: the INI file writing code seems to be total
> crap since it opens, reads, writes, closes the file tons of times
> (which is where my USB slows down).
I'll take a look at this as well when I surface. (Which is no earlier
than Sept. 1st.)
pete m
On further investigation, restarting the computer made startup much
faster, more or less instantaneous. So it looks like there's some
kind of weird resource leak involved.
HTH
pete m
V-dev summoning bug:
I was fighting Feagwath, and he summoned monsters--the Tarrasque,
Atlas, and energy hounds. And he himself vanished. (He was in a
hallway at the time; it's as if an energy hound must have landed right
on top of him.)
This is the second time this happened.
pete m
Another bug: I found a stirs down on dl 99 prior to killing sauron. I
was surprised to see Morgoth, given my deepest kills are Cantoras and
Feagwath...
zai...@zaimoni.com
The current implementation uses Win3.x API functions that are
supported for backward compatibility from Win95 through Vista.
Fixing this requires locating/writing a C library with a compatible
license for handling Windows *.ini files. It may be a while.
ShieTar
*-ini files are text-files, right? Why would you use OS-API functions
instead of standard c file handling for those anyways? Can someone
explain to me what I'm missing here?
ShieTar
zai...@zaimoni.com
> zaim...@zaimoni.com wrote:
> > The current implementation uses Win3.x API functions that are
> > supported for backward compatibility from Win95 through Vista.
>
> > Fixing this requires locating/writing a C library with a compatible
> > license for handling Windows *.ini files. It may be a while.
>
> *-ini files are text-files, right?
They are text files with additional formatting requirements specified
by Microsoft. The additional formatting requirements allow the
Windows 3.x API functions to treat them as a non-SQL database.
> Why would you use OS-API functions
> instead of standard c file handling for those anyways?
*.ini files are a Microsoft innovation to begin with.
In this case, the problem is that each and every key-value update to
the *.ini file via the OS API is causing a temporary file to be
written, then the using the temporary file to replace the old version
of the *.ini file. (This fails if the program doesn't have delete
access to its own *.ini file -- which is the default under Vista for
programs installed under the Program Files folder....)
red_...@hotmail.com
> the *.ini file via the OS API is causing a temporary file to be
> written, then the using the temporary file to replace the old version
> of the *.ini file. (This fails if the program doesn't have delete
> access to its own *.ini file -- which is the default under Vista for
> programs installed under the Program Files folder....)
First a note here it seems angband updates the entire INI file
contents regardless of wether it's been changed or not, so I guess it
would be possible to reduce the newfile/write/delete loops by first
checking wether it needs to be written, this without affecting the
current implementation of those settings (the delete permissions issue
for Vista should probably be solved by using the \users folder in the
long run but more short term could be solved in an installer setting
the permissions).
Second, I think we all agree that though INI files are easy to deal
with, they are something that no one really beleives in. So what would
be suggestions to replace it? What do the other OS ports use anyhow?
zai...@zaimoni.com
> Second, I think we all agree that though INI files are easy to deal
> with, they are something that no one really beleives in. So what would
> be suggestions to replace it? What do the other OS ports use anyhow?
Good question.
I'd be fine using a config file format identical to some other port,
as it's likely that other port's config file format is open-source and
thus easily adaptable. However, that should go into V3.1.0, not
V3.0.9 series.
pete m
Another bug: Social class doesn't get reset properly after death. My
current character is cl 12 and "Lordly."