![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 1 to 5 of 5 total |
![]() |
Thu, Apr 14 2016 9:56 AM | Permanent Link |
kamran | 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 |
Thu, Apr 14 2016 11:37 AM | Permanent Link |
Matthew Jones | 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 |
Fri, Apr 15 2016 3:57 AM | Permanent Link |
kamran | Hi Matthew Thanks your your tips. Regards Kamran |
Fri, Apr 15 2016 2:20 PM | Permanent Link |
Raul ![]() | 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 |
Fri, Apr 15 2016 4:55 PM | Permanent Link |
kamran | Hi
Matthew and Raul That helps to clarify it. Thank you. Kamran |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |