Another tip is not to over do it with the 'snazz'.
The problem with my orgigional Demo site was that I used DynAPI wherever
possible.
I have found that one can use simple HTML or plain javascript
in a lot of places (such as for roll-over menus, or 'dynamic' content).
Which in turn speeds up the site and resduces the mem-footprint.
Doug
----- Original Message -----
From: "Raymond Smith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 20, 2001 12:51 PM
Subject: Re: [Dynapi-Dev] Freeing Memory
> I'm really beginning to think there are two sides to this issue.
>
> 1) Design Methodology.
> 2) Code Optimization.
>
> 1) Eytan eluded to this here, "and then nullify them nothing happens but
> when you recreate them still the memory stays stable". Today most sites
are
> page based, and I think within a common site URL browsers attempt to "hold
> history active" till you leave to an all new destination, then purge
memory.
>
> Everything I have been trying to do is based on using the DynAPI to create
a
> single interface linked to a dynamically created, updated and evolving
site.
> Think of the JS as providing "interface" only. Then you would use dynamic
> content engines to pump new content into "reusable components" using
set"xx"
> methods (heck you could even reskin an object on the fly). This is the
> direction the web is moving anyway with CSS and XML anyway.
>
> There's no reason you couldn't initialize a series of display widgets then
> call them in, resize them and modify content based on user activities. I
> think page based browsing + DynAPI (with any level of pizzazz) is a recipe
> for failure. It will eventually overload the system since every page is
> going to want it's own widget set. Design would be based on creating
sites
> with as tight a "widget depth (how many total layers)" as possible. Reuse
> widgets (if possible) prior to creating new instances of a prototype.
>
> 2) Optimization. I came from a game developer www.angelstudios.com. I
was
> COO and I found the business of "making games" slow and boring. The idea
of
> waiting and working 2 years to see if you have a winner to only see the
> "bounty" get slyly skimmed into the publishers pockets grows old fast).
> Hence, I left the Industry for the fast paced insanity of the web. But
game
> developers are optimization freaks, they have to be.
>
> I did a little research (I wasn't a programmer, I made sure they didn't
eat
> to many Twinkies during a specified month because at Angel we bought all
the
> Twinkies for our employees; kept them coding longer), and just from a
> "tricks of the trade standpoint" our code could be significantly optimized
> with a skew towards the Pentium processor set. I'm sure with additional
> research we could learn even more. Here's what I found so far:
>
> a) API's, in general, are non-optimizied. DirectX works (as an API)
> because it was designed to be as "thin" as possible.
>
> b) Use global variables. Don't use parameters for allot of time-critical
> functions, instead use a global parameter passing area. Example:
>
> void Plot(init x, init y, init color) {
> // plots a pixel on the screen
> video_buffer{x +y*MEMORY_PITCH] = color;
> }
>
> optimized
>
> int gx,gy,gz,color; //define globals
>
> void Plot_G(void) {
> video_buffer[gx + gy*MEMORY_PITCH] = color;
> }
>
> I realize we are an API, but implementing aspects of this where
appropriate
> will help.
>
> 2) Always use 32-bit variables rather then 8- or 16-bit. The Pentium and
> later processors are all 32-bit. This means they don't like 8- or 16-bit
> data words, and in fact, smaller data can slow them down due to caching
and
> other related memory anomalies. Example:
>
> struct CPOINT {
> short x,y;
> unsigned char c;
> }
>
> Optimized
>
> struct CPOINT {
> int x,y;
> int c;
> }
>
> I don't think this applies a great deal to the current API but I am
sharing
> it anyway.
>
> 3) Program in a RISC-like (reduced instruction set computer) manner. In
> other words make code simple rather then complex. Pentium class
processors
> like simple instructions rather then complex ones. Longer simpler code is
> faster then short complex code structures. Example:
>
> if ((x+=(2*buffer[index++])>10) {
> do stuff...
> }
>
> Optimized
>
> x+=(2*buffer[index]);
> index++;
>
> if (x>10) {
> do stuff...
> }
>
> We do sin here a bit....
>
> 4) Use binary shifts for simple multiplication of integers by powers of
2.
> Since all data in a computer is stored in a binary form, shifting the bit
> pattern to the left or right is equivalent to multiplication or division.
> Example:
>
> int y_pos = 10:
> // multiple y_pos by 64
> y_pos = (y_pos << 6); //2^6=64
>
> Similarly,
>
> //to divide y_pos by 8
> y_pos = (y_pos >> 3); // 1/2^3 = 1/8
>
> Disadvantage... confusing code to some.
>
> 5) Write efficient algorithms.
>
> 6) Don't write complex data structures for simple objects.
>
> 7) Don't go crazy with inheritance and layers of software. Keep the base
> as lean as possible.
>
> 8) The Pentium-class processors use an internal data and code cache. Be
> aware of this, and try to keep the size of your functions relatively small
> so they can fit into the cache (16KB-32KB+). Store data in an accessible
> way, it minimizes cache thrashing and main memory or secondary cache
access,
> which is 10 times slower than the internal cache.
>
> 9) Use precomputed "look-up tables" when possible.
>
>
> So, I think that freeing memory and optimizing speed will be the marriage
of
> a quality site design/interface and a well constructed code base to draw
> from. While some users will elect to take a more conventional path I
think
> this will ultimately lead the the best "final result". But hey! I'm just
a
> designer...
>
> Ray
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
