Hi

Just need some advice and best practice for use of EWB with EDB tables.
(e.g. efficent loading and better managed coding/use of)

1. Minimising initial load time

I am aware that the javascript can be compressed to decrease the load time.
a. Anything else I should consider?

2. Memory management while in application in use

a. is it better to create all screens in one go ?
or
b. create a screen,  then use it, then destroy it?

What about global variables ?
should they all be defined on the loadup/ first screen
does it matter from memory management point of view ?

Is the local datastore a better way to do it ?

3. Using datasets (tables)

a. Is it better to have one screen with all datasets defined on it ?
and then reference this screen when required.

or
b. define each dataset on the screen where it going to be used then use it.
(I find this method redious to manage - (especially if any fields have been added or changed in structure)

3. Using images:

a. In controls. eg TImage as a button (it obviously increases the load size and time)

Any tweaks here ?

b. Loading and displaying selective images / sound / video etc

I guess you would just load it, use it then free it
Storing these in a table might be too much to handle ?

What has been your experience and best practice ?.


Kind regards


Kamran

kamran wrote:

> 1. Minimising initial load time
>
> I am aware that the javascript can be compressed to decrease the load
> time.  a. Anything else I should consider?
>
> 2. Memory management while in application in use
>
> a. is it better to create all screens in one go ?
> or
> b. create a screen,  then use it, then destroy it?
>
> What about global variables ?
> should they all be defined on the loadup/ first screen
> does it matter from memory management point of view ?
>
> Is the local datastore a better way to do it ?

I can't answer the database side, but will comment on these. First,
there are two load times - first from the server to browser
(compression), and then the time to display something useful. FWIW, I
am creating screens on first use, but then keep them around for
re-display later. The cost is in making all the browser DOM objects, so
no point destroying them. But I also have a timer on 50ms that does the
data loading. This way the form appears, and a panel will say
"loading". Then the data can be loaded, and the user wasn't stuck with
a pause and nothing happening.

Global variables will be there all the time - obviously anything you
load into them will hang about. Again, no point freeing anything you
will re-use. The local data store would be a good place to cache some
things to save a round trip to the server.

--

Matthew Jones

Hi Matthew

Thanks your your tips.


Regards


Kamran

On 4/14/2016 9:56 AM, kamran wrote:


> Just need some advice and best practice for use of EWB with EDB tables.
> (e.g. efficent loading and better managed coding/use of)

These are important things to think about. I would say that don't try to
optimize prematurely - if there is no issue to begin with then
optimization would be time you can spend on something else.

Some of the answers below also depend on what your weakest link is in
terms of device and connectivity :

Modern browser on PC with fast internet connection might not need much
on anything in terms of optimization.

Mobile phone on 3g (or 2g) will be more limited in all aspects - slower
connection, more latency, slower CPU and possible slower JS engine and
browser.


> 1. Minimising initial load time
> I am aware that the javascript can be compressed to decrease the load time.
> a. Anything else I should consider?

There are really few levels of compression here if you want to get into
details:

- EWB has a "compress output" option that you should use. I consider it
more an optimization as it reduces the size of javascript files
significantly but output is still fully functional JS (i.e. no
decompression is needed on receiving end).

- in addition if your web server (and browser) support it one can also
enable actual compression on server level (usually gzip).

This would apply to all traffic including the EWB JS file but also
actual JSON data that is exchanged when accessing EDB database data.

Whether gzip type compression helps you though depends on your EWB app
data usage and you would need to test (if you infrequently
download/upload small amounts of data that fit into a TCP packet then
it's really just wasteful overhead; if compression would help you reduce
number of actual TCP packets sent on wire then it's beneficial).

One thing to also consider is that send as little as possible data
across wire : only download what you need both in terms of fewer rows
but also only retrieve columns that you actually use (avoid the "select
* from <table>" pattern).


> 2. Memory management while in application in use

Matthew already covered this well but main thing to consider is that
you're running in JS virtual machine with JS garbage collection so
avoiding frequent create/use/delete cycles (better to keep things around
in general that you frequently use)


> 3. Using datasets (tables)
>
> a. Is it better to have one screen with all datasets defined on it ?
> and then reference this screen when required.

I don't know for sure but i doubt it really matters since storage
requirements would be same (as long as you're not creating/destroying
them all the time).


> 3. Using images:
> a. In controls. eg TImage as a button (it obviously increases the load size and time)
> Any tweaks here ?

Anything that's accessed and loaded as a URL link should get cached by
the browser so you're avoiding network trips and such. I'd suggest to
not load them as tables - you'd be manually managing bunch of binary
data that browser can automate for you.

Raul

Hi

Matthew and Raul

That helps to clarify it.

Thank you.


Kamran