World: r3wp

I agree with you Maxim.

But on the other hand, I never allow my team to sacrifice the readability 
unless IF there is a really good reason to do that AND IF they put 
enough comment WHAT and WHY they do that. Otherwise it wastes our 
time to "solve" the optimisation a few months later.

Optimisations are good / necessary if they are (can be) in loops 
(mostly), but they are dangerous especially if you are writting lower 
level code (mostly C, even Java) because compilers use code-patterns 
to optimize your code, so your hand-optimized code prevents compiler 
optimizations on modern compilers.

And worst, if you are using assembly, your optimizations may prevent 
to use CPU caches and for example when it works faster on one CPU 
it can be even slower than the original version on another CPU.

By the way, I tested on 3 different PC with R2, while loop was always 
faster then the until loop in the above case. Of course I didn't 
test the real case (using do-sql with millions of rows)

And of course Carl should write very optimized code in REBOL because 
everything else is depend on it. 
Hmm I think we should move to another group :)

If I had the same opinion, liquid would still be 10 times slower 
than it is now.


That's big enough to matter, not just measure. I think, that's what 
Gregg pointed out. And remember, there is not a final truth about 
this, as what matters to one person, might not to another.

It doesn't really matter if you get a 133% increase in the speed 
of glass if it has been abandoned for Rebol! lol

My thoughts, too. There's also the matter of why REBOL and AltME 
are such slow memory hogs if Carl's code is so good. The reasons 
are found elsewhere. REBOL systems have aspects of penny wise, pound 
foolish. The actual code needs to be optimised to limit the damage 
a bit

Has Carl been the sole developer of Altme ?

I believe in optimizing on a case by case basis, as most do. And 
I believe in optimizing different things in any given case. Size, 
speed, felxibility, and readability are all fair game for optimization.


As far as AltME and other slow REBOL UIs, I remember Carl saying 
once that View is a miser, saving pennies, while VID is the government 
and spends millions. I think whoever designed the list model used 
in AltMe and other apps (e.g. IOS conference and messenger) chose 
to make the implementation small and quick to write, knowing that 
they might not be fast. They may also not have imagined how far they 
would be pushed.

View is a miser...

 That certainly depends on how you use VID. VIew's SHOW function is 
 a big bottleneck and the most important function of all to optimize 
 for. But yes, AltME lists are rather heavy.

Altme is a slow UI? Just don't make me laugh, those who claim so. 
Have you tried Azureus? That's Java. Altme just runs ok. We all know, 
that the UI is not OS compatible, so there are things to be desired. 
And altme server can run for months without a restart.

Altme is consistent speed wise. I have 3 years not reinstalled my 
Vista, so once my ntb boots, it takes 5-7 minutes to be usable.I 
click on many apps to start, and Altme definitely starts first. Stuff 
as Outlook, Firefox, etc., take usually tens of seconds!

Well, this belongs to Altme, or advocacy, sorry.

The most important thing in optimization is to decide which part 
should be optimized.

If you optimize INSERT, even 0.1%, this gives a huge difference. 
But optimizing something in your INIT function which will be called 
once when the app. start.. I would say don't sacrifice the readablity.

So optimizing core is almost always necessary (like R2/3 function, 
functions in frameworks like LIQUID),

Optimizing the functions in your app. or the app. itself, only if 
it worths.

Maxim: you are mostly talking about the overall performance gain 
in the whole system. But the case above (Cheyenne, do-sql bug) we 
gain 2-3% performance just in do-sql function, IF it's used in a 
millions loop (or returns a few millions of rows) AND only IF you 
use native drivers AND only IF you use /flat refinement. which leads 
very rare cases. So the overall perfornance difference is  very very 
low. (well, still WHILE faster than UNTIL in above case anyway..)

Doc: I've solved "Cheyenne cannot be installed as a service on Windows 
2003 Server" problem.

service.dll requires msvcr71.dll to run, if not present Cheyenne 
crashes with "** Access Error: Cannot open service.dll as library" 
error.

msvcr71.dll file should be present in same folder with service.dll 
or better it should be in %windir%\system32 (or the correct path 
if 64bit OS)
I think we should note this dependency somewhere on the web site.

Right, I should also recompile it with a more recent version of msvcrt 
library I guess.

Its better Cheyenne should write (create) a msvc71.dll if it is not 
already in the same directory. Because when I search for that library 
I see that almost  every program has that dll in their own directory.

Because we cannot trust that the correct version will be in the system 
folder.
OR a better error handling/message for this error  :)

SQL Server, Office, Java, SVN, Photoshop.. they all have it in their 
own directories.. But older versions of Windows don't have it default.

It would at least double the size of the Cheyenne binary, for a feature 
only a few use. I would rather prefer to provide links for downloading 
the right DLL for each Windows version.

All the software you are listing are bloated software that don't 
care to follow the basic rule of sharing libraries, especially when 
it's the libc.

I think that the following package installs the msvcr71.dll file: 
http://www.microsoft.com/download/en/details.aspx?id=5638

You are right, giving a link is better than including the whole dll.

What do you think about making a setup package for Windows? Including 
that dll and some configuration options during the setup, service 
mode default, etc.
If do you think its worth to do, I can do it.

One of Cheyenne's selling point is: no installation required :-)

@Endo, you can do it, and Doc can link to it :)