I am currently working on a modular application which contains lots of modules and i am loading the modules using ModuleLoader which load the modules faster that are contains less number of visual components,But the modules which contains lots of visual components then it takes lots of time to load the module.For example i have created a periodic table which contains all the elements and each element is a custom component when i load the module it is taking almost five seconds to load and it freezes the main application.I have to load the same module for multiple times in my application which makes the application very slow.
Is it possible to load the module faster or preload the module so it can be added to the stage faster or any other suggestions?
Related
Okay so I have around 20k records and 29 columns of text-only data that i fetch from a back-end into an Angular app.
once I get the data from the server (takes around 1s) I bind it to a field in a component and then use an HTML table combined with *ngFor to display all the data.
Chrome takes about 58 seconds to render everything in one go and scripting time is around 10s.
it is a big requirement for my company to be able to see results in the page in under 2.5s from the moment I click on the link to the component without using pagination or infinite scrolling.
what are my options to achieve such performance?
It's hard to tell with limited knowledge about the app and model but I see 2 options (you can go for one or both):
lazy load paginated table content. I don't know which (if any) UI framework you're using but you can check how it's handled in NgPrime for instance Lazy table
EDIT: It can be realized in few ways:
First: if backend is problem (not in this case) you can request only slice of data from backend and handle it with some library like NgPrime
Second: if you're not using any framework you can use something like virtual scroll Virtual scroll
slim down model which is sent over the backend. If large collection of objects has some nested objects as props it can significantly slow down both download and rendering. Instead of having nested object you can decide whether you really need all data which is trasferred and make some light object instead.
Also check out dev tools and analyse loading performance to get more info:
Find bottlenecks in chrome dev tools
EDIT:
With more data provided from comments, I would use virtual-scroll or similar mechanism (it loads and renders html dynamically).
This may be a really silly question. I admit I'm a bit naive to the chrome web engine, and JS v8 engine's capabilities.
But say, I'm running a puppeteer application which is scraping URL's from tags, and pushing them to an array called img2arr
Then, I have a local file var img1 = ./image.jpg (in quotes).
Last, I have a function compare(img1, img2arr) which takes in both of these as arguments, and using a library such as blink-diff, or Jimp, analyzes and compares img1 against each image in img2arr. This all happens in a .forEach() or .map loop which works, but can be slow as the image2arr grows.
Say it contains 500 image URL's - is there a way to use service workers, a specific Node.js library, or anything to ensure that my image looping and comparing logic all happen across multiple threads?
For instance 200 loops, comparing two 12KB images takes 7 seconds, but with my blazing fast 12 cores processor couldn't it take less than 1?
Sorry for my obvious naivety!
There is a few possible ways:
1. Use spawn to run separately your script on every core of your machine. Here is really nice article.
2. Use node.js worker threads here is you can find how it works with examples.
Not depending the way of implementation you decide, main part would be to collect all data, up to this point
Last, I have a function compare(img1, img2arr) which takes ....
Then, separate your array of img2arr to chunks. You can choose any method from this article
After separation, pass each chunk to separate process and wait for first process to find the similar image.
When the process finds out similar image, you can kill all other processes from your master process.
So, the full process would be:
1. Collect images to compare
2. Split images to compare into chunks.
3. Separate comparison logic to separate file and run a thread/process on this file.
3a. Send chunks to available process
3b. Wait for first success return from process and kill all other ones.
I currently have 6 animated models each between 5Mb and 8Mb each. When using each one individually it can take a little time to download them. I need to load these models up as and when I need them and not in the preloader of libGdx. All 6 models will take a long time to download in the preloader so I'm trying to bypass it.
I've used both GWT and libGdx many times but not together. This project is purely a html one and I'm familiar with classes that need to be serialised so data can be transferred back and forth using GWT's RPC methods.
So far I've come up with 2 ideas of doing this:
Transfer the model data and rebuild the mesh from scratch. This
would take a lot of time and just wouldn't work. Plus it's likely I'll lose such data like animations.
Using LibGdx's
ModelData class which would work perfect, but unfortunately non of
the main class and sub classes are serialised.
The current project has interfaces that bridge the platform specific from the 'core' to the 'html' which can then async the RPC calls. These work with libGdx just great.
Is there a way of skipping the preloader and loading the models on demand when they are needed?
If you need anymore information I'll be glad to add that in.
Take a look at the Dynamic Asset Loading with libGDX and GWT example by MonsterOfCookie: https://github.com/MonsterOfCookie/libGDXGwtHtmlExample
Disadvantage is that you have to compile your own libGDX fork because Monster's PR was not merged. (But for working seriously with libGDX' GWT backend you'll probably need your own fork anyway)
Is there any way possible to say, have A.swf use only certain items from B.swf, without having to load the entire swf as a child first? What i'm trying to do is have A as lite as possible and pull some items from time to time from B without having to cache the entire file in flash memory somehow. I've looked at other similar questions but none seem to really answer or fit this exact problem.
Before anyone asks, yes I do know how to use loader, loadercontext, and create instances of classes from the library. This is more of a methodology question rather than a "how to" question.
Only idea I can come up with, is to export all of the children as individual swf objects and then have A request B to compose itself of the seperated items that get requested by A. Would this be efficient?
I don't think you can do what you want to do, however since the assets are strictly graphical in nature, it doesn't seem inefficient to just export them as individual assets and load them when you need them. ( In fact it seems very efficient to me... )
I haven't tried it, but to save time you could probably automate the export process with jsfl. ( Jsfl lets you script the Flash IDE itself, to automate tasks that you would otherwise have to do manually. ) Take a look at this Stack Overflow answer here:
Generating individual SWF's with classes from a fla with a large library
That example shows how to batch export swfs out of the library.
Note than in Flash CS6 you can export a MovieClip from the library by right clicking and selecting export, but unfortunately it doesn't let you export a group all at once.
A swf is a compiled package, and is not meant to be split into parts. One solution would be to pull all of the common elements out of A and B into a swc (a compiled Flash library, not meant to be run). You can then include the swc in the compilation of A and B.
Unless you will be creating lots of files with only a few common elements, I don't see why you would need to export each of the children as individual swf files.
I have this relatively large web app, it is a single page with ajax calls for the business logic.
Currently I have a small html file that loads all css and js files, and then loads the actual content of the page using ajax, so I have like 15 html files to load a single page (each html file is a "div" in the main html page.
Several files are easier to maintain, but my question is: what is better in terms of performance / User experience?
Keep it as is now (several files loaded async) OR have a script that joins all the files on "compile" time (when deploying)?
I understand that having a single html file is more efficient in terms of network performance, but on the other hand a small file will load faster, and the rest of the content will load after a "loading" dialog.
It is better to have less files as scripts block and load sequentially, or use deferred loading. There is normally a per domain limit for parallel downloads although I cannot for the life of me remember what it is.
For production if you compile a single payload for the scripts together and all of the stylesheets together you will likely reap some performance benefits. I would also consider minifying the output as well. Yahoo Compressor and Google Closure Compiler are two tools that can be used to achieve this.
This will tell you more about the techniques to stop blocking...
http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/
Some performance tips, not limited to JavaScript...
http://developer.yahoo.com/performance/rules.html