New template in the works.

[Mars]

It is as for a RUBIK'S CUBE, the speed with which you find the solution, depend on the used method.

Certain macro are faster than variables %symbol%, and conversely.
Everything depends in which context they are used.

If we have a symbol and a macro which make the same spot, they appeal to the same function in the language delphi.


The php, it is as of the javascript, but executed by the highly-rated of the server.

if you place alot of macro's in a template, would that significally reduce the speed on slower computers?

It is always the same problem, any depend of the way you order your code

if x=a then a();
if x=b then b();
if x=c then c();
....
if x=z then z();

it is faster to do

if x=a then a()
else if x=b then b()
else if x=c then c()
....
else if x=z then z();
the next

if x= b then test is closed and continue to 'the next'

[TSG]

Can we make this one quicker... I'm not too happy with it being in 4 lines...

{{if|{{is substring|127.0.0.|%ip%}}|{{$update-mod}}}}
{{if|{{is substring|10.0.0.|%ip%}}|{{$update-mod}}}}
{{if|{{is substring|10.1.1.|%ip%}}|{{$update-mod}}}}
{{if|{{is substring|192.168|%ip%}}|{{$update-mod}}}}

[Mars]

{{if|{{is substring|127.0.0.|%ip%}}|{{$update-mod}}}}
{{if|{{is substring|10.0.0.|%ip%}}|{{$update-mod}}}}
{{if|{{is substring|10.1.1.|%ip%}}|{{$update-mod}}}}
{{if|{{is substring|192.168|%ip%}}|{{$update-mod}}}}

replace it by

{{if |{{match address|%ip%|127.0.0.;10.0.0.;10.1.1.;192.168.}}| {{\ $update-mod /}}  /if}}

'127.0.0.;10.0.0.;10.1.1.;192.168.'   is passed to hfs as one parameter (as a mask).



new usage : '{{\ '   macro ' /}}'           at the place  of  {{macro}}  when you use  macros into a if even you get some error ( look at wiki about this) http://www.rejetto.com/wiki/index.php?title=HFS:_Template_macros#Problem

[TSG]

Doesn't work. Copying what you have directly shows as a broken macro, and editing it to work properly, it doesn't work... I'm not trying to match whole address's just parts of address's.

[rejetto]

I mean, if you place alot of macro's in a template, would that significally reduce the speed on slower computers? (E.g. my 500mhz server).. Or is it barely noticeable

test and let us know. 

{{if |{{match address|%ip%|127.0.0.;10.0.0.;10.1.1.;192.168.}}| {{\ $update-mod /}}  /if}}

you must add {{\ ... /}}
not just \ ... /

so, it's
{{if| {{match|127.*;10.*;192.168.*|%ip%}}| {{\ {{$update-mod}} /}}  /if}}

[Foggy]

I mean, if you place alot of macro's in a template, would that significally reduce the speed on slower computers? (E.g. my 500mhz server).. Or is it barely noticeable

test and let us know. 

Out of curiosity last night I tested the ToG and TSG's new template on the same vfs consisting of 10.8k items.
The results were, ToG 54 seconds build time
and the new template 66 seconds build time

even though the tog was faster I think that the macro's are faster in general because you have to take into consideration how many macro's TSG has used for each file, and someone would be crazy to recursively list a vfs of 10.8k items let alone a have single folder of 10.8k items.

[maverick]

Foggy,

Are you sure about the results - 54 seconds and 66 seconds?  Those build times are just less than a minute on the first test and just over a minute for the second test.  Those are very slow results to build a page.  Maybe you meant 0.540 seconds and 0.660 seconds.

[Foggy]

Yes, I am sure. Like I said above there was about 10,800 items being listed. I also used two instances of HFS to avoid any possible caching.

[TSG]

Local testing is a lot slower than external, i have noticed this by testing over the network, cause the browser will use 20-30% of the cpu loading the page, and hfs about 10%... and if ur listening to music thats another 5%ish might want to run the test again over the internet with only hfs and the browser running on the host and client pc's

Those results are correct for the test. if you do the math, its about 0.004 - 0.005 sec / row.

Even so, the results are impressive considering the amount of characters/row and like foggy stated, the amount of macro's in use in the new template. The macro system is considerably faster.

[rejetto]

I don't think we need the macros to be faster.
It is more powerful (because some things can be done only on the server and not in javascript).
It is more compatible (because you know the compatibility problems of javascript).
It is a choice (because you can always keep using javascript if you want to).

So, even if it is 10% slower, it would be a normal price to pay.

p.s. take in account disk caching over different tries

[TSG]

Last night I was able to remove 2 more javascript page load functions with macro, you can expect these updates in ToG and Terayon once this new one is out in the public.

What else... I've hopefully fixed the foriegn character bug with 'encodeURI' in place of 'escape' and decodeURI' in place of 'unescape'. I was going to respond to the topic but i couldn't find it, might be in the 'other language' board.

Also this template is w3c standard as xhtml, there is just 'name' errors caused by encoded characters in the name field, which i can't do anything about.

Few bugs to iron out with the preview box but it's getting there

[bacter]

Consideration about speed of templates:

1. Parsing macros and replacing them by code or values will last some dozens of nanoseconds. Optimizing macros you can perhaps save some microseconds on the whole template!
2. What may be time consuming is access to disk, when not all data is already in the cache of the disk. Disk access to directories or to images or to files to be included may each be at about 10 miliseconds, this will especialy be noticed when you do things recursive or you are searching.
3. The most slow part is shuffeling out the generated page to the net. With an uploadbandwith of about 300 kbps, a 50 files page(about 25 kB) will last about 1 second, a 300 files page (100 kB) will last 3 seconds(you have to add the filesizes for images,backgrounds etc. that are not already cached on client-side).

Conclusion:
A) Using macros will create faster individual pages than java script, because decisions are taken and data manipulated on serverside, what allows to reduce the size of de code to be sent.
B) Try to hold code in recursively used sections like file,folder and link short, as this may increase the size of the generated page.
C) You can save time using external stylesheet and javascript files, as they can be cached on client side, so the generated pages are shorter.
D) Optimizing the code of macros for speed will result in about the same difference as your bodys weight after or before shaving.

[TSG]

I'm not too concerned about speed anymore, it is all relative. But that is a detailed explanation

[TSG]

First beta is coming,
I have decided that I will release a first beta in the default blue theme to get the template out there. I have been rather busy traveling and doing other things lately. So far it is bug free from what i and my bug tester foggy can see, i just need to implement searching and it will be ready for the first beta release. Hopefully sometime tonight or tomorrow...

[TSG]

lol 2 days later, i'm close, search is implemented, bugs are fixed, i just need to figure out how to detect values in the url with macro and i can finish it off. For those that feel helpful, what i need to do is detect for example ?search= in the url to create  no search results error page, i did it with javascript previously but i want to do it with macro. Values that i need to detect include, ?search=, ?filter=, ?files-filter=, ?folders-filter=, this will then change items on the page. I also need to grab the urlvar and show it in the default search field, that shouldn't be difficult i think there is a macro to do it already.