Apologies if this sounds strange, but I'll try to describe what's happening as best I can. We were provided a small service that provides a single form UI that we capture the results of via an event. We've integrated this into two applications and we're seeing some different behavior when we load the UI in a modal window via an iframe. When integrated into one UI it loads pretty quickly. However, in the other UI it takes several seconds to load. Now, the only difference I could find is that setTimeout is being triggered sever seconds after the model is created. I discovered this using the Firefox development tools in the Performance tab.
Now, I believe that the UI for this form is built in a non-recent version of Angular (AngularJS?) based on some Google searches using strings that I could see in a minimized polyfill.xxxx.js file. However, I can't understand the code that was minimized and I have no version information to help me get back to a version that I can try to read and understand.
I did testing using the Performance API before the iframe is created in case the issue was something in my code, but the tested code is finished in < 100ms, so that didn't appear to be the issue. It's not a network issue as the requests occur pretty quickly. Also, both applications are referencing the same instance, so the only difference is the app that it's integrated into.
So, my primary question is what could be causing Angular (AngularJs) to set a timeout on page load? My secondary question is what advice is there for trying to debug this? I don't use Angular at all, so I'm not even sure where to begin outside of what I've already tried. The only custom app code I see looks to be Angular configuration/properties, so no JavaScript to debug.
The best advice with setTimeout() in such a situation is to not use any setTimeout().
I ran into same situation not only angular most of the framework treat setTimeout() a bit differently.
What I mean setTimeout() in a plain JS app and angularJS app and Angular App will differ the time interval.
setTimeout() is set to execute after a certain time, but that's is not guaranteed by the thread.
Some time angular completing change detection and watcher life cycle, all mingle with setTimeout() and you will end up with strange behavior.
So better not to use that unless you are sure it's not gonna mingle with other running things.
Please share the code snippet if possible
Related
I am using fullcalendar and I really like it!
I am developing a simple application which needs to show a calendar able to rendere lots of events every day/week but I am facing an issue, since the pure web HTML/JS application runs in an embedded device with a chromium-based browser when I inject the events (let's say 1000 in a week in the week view) it tooks a lot of time, doesn't matter if I do it by .addEvent or .addEventSource, I also tried to put them inside a .batchrendering callback but no luck..
Then I tried to load them using the "events (as a function)" way but still it is slow.
The events data is retrieved by my AJAX callbacks in a centralized way thus I cannot use "events (as a JSON feed)" method.
The strange thing that I noticed is that the successCallback or the .addEventSource call returns after some reasonable time but then, the system, remains blocked for a lot of time, if I try to inspect the HTML I can see that the generated elements are destroyed and created again for a lot of time keeping my cpu at 100%
Is it a known issue or am I doing something very wrong?
Which should be the fastest way to insert the elements?
Note: I am using the fullcalendar v4, could be v5 a more powerful alternative?
Thanks :)
All,
A company I'm working with outsourced some development to a third-party company. The developers at this third-party company are "using" Ng 7 (using in quotes, because much of the functionality is hand-written instead of using what's out of the box).
The app is VERY sluggish.
Inside the root component, I call a service's init method. The init method creates a start time and then calls and observer on the applicationRef.isStable object. When the application becomes stable, it returns to the init method that then gets the end time and calculates a delta between the end and start times. This delta is then printed to the console.
The difference in time ranges anywhere from 60 second to 200+ seconds.
Obviously, the code has issues as it shouldn't take 3+ minutes for the application to become stable.
Question:
Is there a tool that can help me troubleshoot what's taking so long for the application to become stable?
Thanks.
I would go with chrome's performance:
Check for guidance on google's guide
Checking on the network tab could also help, to figure out if it's XHR requests that are causing the problem
I have a website which has many pages that are not exactly the same, but one thing they have in common is that on each page there are some tabs, and if you click TAB A, certain information shows up, then if you click TAB B, other information, etc.
I know that it is very easy to use Angular to do this, and I wish to use it, however I do not wish to convert the entire site to a full Angular application. I simply want to include the Angular javascript file on every page of the site, and only use the ng-hide and ng-show functionality for these tab items.
So my question is: Will it affect a user's experience much if every page he goes to on my site has to launch Angular again? I am not worried much about the network times of downloading Angular.js because I am sure I can configure caching so that the actual script doesn't have to reload, but what I am considering is the CPU/memory aspect and whether it will result in an extra period of time for every page to load - this is already an issue on this site, so adding an extra 0.5 seconds (let's say) would be undesirable.
This guy here tested something like starting up many angular applications at once
This buddy conclude that caching can be pretty expensive if you decide to preload everything.
My personal and empirical opinion, if you started with something, it might be the case for you to stick with it and try to solve your problems with what your current framework offers. As you said, you don't need anything very angular-specific, it is just a couple of things.
I would recommend you not using a entire framework in case you want just a simple functionality from this, keep it simple and easy.
whether it is partial update or full update, every postback to asp.net server results in running full page life cycle. which means, page_preinit, page_init, page_load functions are run before what actually we want to run what we wanted to show.
Sometimes, we might need to change a small thing, but the slowness of running entire page life cycle sucks.
any help. any technique?
Here's some help:
Don't overload your page lifecycle events with too much code.
Check in your methods if you are in a post back, an async postback, or a regular request so you run only the code you need.
If you are running code you shouldn't be running on each little postback, that's your own mistake. The lifecycle is there to allow you to do what ever you need to do. Don't blame Microsoft if you choose to run unnecessary code.
You can use JavaScript to update only parts of the page on the client, without having to reload the whole page. Here's Microsoft's take on it.
The page event lifecycle is fundamental to the way asp.net forms work, and can't be avoided unless you want to write http handlers for specific urls/requests which would be overkill (using the wrong tool to solve the problem).
However, the asp.net page event cycle is not slow - it is very very fast. Unless you've done something to add code in those events to slow it down. If your post-backs are slow, you need to profile the activity going on or otherwise debug what's going on rather than try to avoid the page life-cycle.
You could move to ASP.net MVC (it can live side-by-side with asp.net webforms). It has a simpler event model to work with. That doesn't mean you can't overload it with extra code via Filters in the same way people load up asp.net page lifecycle events. Moving to asp.net mvc just to solve a performance problem with asp.net page load time is kind of like opening up a new checking account when you can't get the old checking account to balance... it will only give temporary relief :) :)
I use JavaScript for rendering 20 tables of 100 rows each.
The data for each table is provided by controller as JSON.
Each table is split into section that have "totals" and have some other JavaScript logic code. Some totals are outside of the table itself.
As a result JavaScript blocks browser for a couple of seconds (especially in IE6) :(
I was consideting to use http://code.google.com/p/jsworker/,
however Google Gears Workers (I guess workers in general) will not allow me to make changes to DOM at the worker code, and also it seems to me that I can not use jQuery inside jsworker worker code. (Maybe I am wrong here?).
This issue seems to be fundamental to the JavaScript coding practice, can you share with me your thoughts how to approach it?
Workers can only communicate with the page's execution by passing messages. They are unable to interact directly with the page because this would introduce enormous difficulties.
You will need to optimise your DOM manipulation code to speed up the processing time. It's worth consulting google for good practices.
One way to speed up execution is to build the table outside of the DOM and insert it into the document only when it is completed. This stops the browser having to re-draw on every insertion, which is where a lot of the time is spent.
You are not supposed to change the UI in a backgroundworker in general. You should always signal the main thread that the worker is finished, and return a result to the main thread whom then can process that.
HTML5 includes an async property for tags, and writing to your UI from there causes a blank page with just the stuff you wanted to write.
So you need another approach there.
I am not a JS guru, so I can't help you with an implementation, but at least you now have the concept :)
If you want to dig into the world of browser performance, the High Performance Web Sites blog has heaps of great info — including when javascripts block page rendering, and best practice to avoid such issues.