RE: [Dynapi-Dev] Freeing Memory

[Pascal B. <pa...@dy...>]

ke.. some thoughts.

Javascript is interpreted.. so all of your Pentium /cpu ops.  might not be
of any concern.
We need to make sure the JS parser handles it the quickest.. this could pose
another set of rules then your cpu rules.

Sadly we have no clue on how the JS parsers work, and what they like more,
so we should try these things first before using the compiled language like
optimisations.



Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Raymond Smith
> Verzonden: dinsdag 20 februari 2001 21:51
> Aan: dyn...@li...
> Onderwerp: 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
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>