This feels like a silly question, but what do the various numbers mean on react-native performance monitor? I haven't been able to find in the docs.
I understand RAM. What are the others? What do the two separate numbers mean for Views? Is that frames per second? What should I read to in order to become competent on how to use this tool? How reliable is this tool? What benchmarks should I be aiming for?
Thanks #diedu for posting a link (to a post, which has a comment w/ this youtube vid):
Here's a basic list of what each of those things represents.
RAM: memory
JSC: Javascript heap / memory. Will only be updated as garbage collection occurs.
Views: Two numbers. Top number is the number of views on the screen and bottom is the total number of views in the component. Bottom number typically larger but usually indicates you have something that could be improved / refactored.
UI: main frames per second
JS (not pictured in Q): javascript frames per second. not rendering js but still good to monitor.
Hope this helps someone.
Related
I've been trying different tiling WM's to see which one best fits my needs. Every time I try a new one, it looks good but I find other things that don't quite work the way I like. My requirements have evolved as I go. Initially, I didn't want to get into Awesome because having to learn Lua is not on my wish list but maybe I should give it a try IF it can do what I want better than the other tiling WM's out there.
I'm going to as specific as I can about what I want. I am running a 3440x1440 monitor. I want to use as much vertical space as possible (meaning, a full width, persistent but mostly empty status bar is not an option, but I do like the notification area and a date/time).
I understand it may not do everything exactly the way I want, which is oke. If it does more or less most of what I want I can weigh my options between Awesome and other tiling WM's (actually, only i3 which is what I'm using now but I'm open to better suggestions). I would very much appreciate it if people don't just say no to something it can't do, but say "no, but it can do ...". In other words, feel free to suggest alternatives that might be helpful as well.
Divide the screen in 3 columns, initially 30/45/25, with the right column split horizontally; Fully adjustable and resizable as needed during my work session;
Persistent layout; when closing the last application in a tile, I don't want that tile to disappear and the remaining tiles to resize. Just show an empty space and leave all tiles as they are.
tabbed tiles, so I see which applications are running in a tile (similar to i3).
Resizable tiles with the keyboard into 1 direction; When making the middle column/tile wider, I want that into a specific direction into another tile and leave the other side alone.
Certain applications I want to always launch into a specific tile. For instance, terminals always go into the right-most column top/bottom, browser/spotify always into the middle, atom/IDE always into the left. Some applications should always be floating. Obviously I want to be able to send them to a different tile after launch.
I don't want a 100% width status bar. It will be mostly empty which is a waste of screen estate. Preferably, I'd like a statusbar part of a tile, for example in the right-most tile, resizing with it. Otherwise I'd like it to be fixed to 30% and allow tiles which are not beneath it to use the full height of the screen. My reason for a statusbar is mute; I actually only want a notification area and a date time permanently visible. I don't need a "start menu", dmenu or similar is perfect, which I believe it has integrated.
Many thanks in advance!
The general answer is "Awesome configuration is code and it can do whatever you want". But there is a catch. Can Awesome be configured like you describe? Yes, totally. There is at least 2 distributions coming close enough (mine[1] and worron[2]) (at least for the tiling workflow, not the look).
The "catch" is that the workflow you describe isn't really the "Awesome way". Awesome is usually used as an automatic tiler. You have layouts that describe a workflow (code, web, internet) and manage the clients according to their programming. Manual tile management is rarely necessary once you have proper layouts. That doesn't mean you can't, I did, but it might be worth thinking outside the box and see if you can automate your workflow a bit further.
Also, the default layout system isn't very modern and makes it hard to implement the features you requested. My layout system (see link below) can be used as a module or as a branch and supports all features described above. Awesome is extremely configurable and it's components can be replaced by modules.
https://github.com/awesomeWM/awesome/pull/644
The layout "serialization" documentation is here:
https://elv13.github.io/libraries/awful.layout.html#awful.layout.suit.dynamic.manual
It is similar to i3 but has more layouts and containers. As for the "leaving blank space" part, it is configured using the fill_strategy:
https://awesomewm.org/doc/api/classes/wibox.layout.ratio.html#wibox.layout.ratio.inner_fill_strategy
As a word of conclusion, I would note that what you ask is "work exactly like i3". If you want such thing, well, use i3. Awesome is a window manager framework. Its goal and purpose is to create a customized desktop shell / WM. If it's what you want, then go ahead and learn it, nothing else can come close to the possibility and the level of control you can get out of it. However it takes time and effort to get to the point where you have "your own perfect desktop". Our users perfect desktops:
https://github.com/awesomeWM/awesome/issues/1395
[1] https://gfycat.com/SmallTerribleAdamsstaghornedbeetle
[2] https://www.youtube.com/watch?v=-yNALqST1-Y
The WM your are looking for is herbstluftwm (hlwm). Its a manual tiling window manager. The tiles which you are talking about are called frames in hlwm. Each frame can contain multiple windows. A frame can also be empty. Only if you kill a frame the other frames will automatically resize. You can add new frames vertically and horizontally and resize them. Each frame can also have a different layout to organize the windows inside. The layout you are looking for is max. This will stack the windows inside a frame on each other. It doesn't show you tabs like i3 however. hlwm allows you to create rules to open certain applications always in certain frames and workspaces. hlwm doesn't have a statusbar buildin. I personally like to use tint2. It can be used as a replacement for your requirement to see running applications as tabs.
let me start off by showing that I have this UIImageView set up in my ViewController:
Each one of the lines contains a UIButton for a body part. If I select a particular button, it will segue me appropriately.
What'd I like to do is, when the user taps (but doesn't release) the button, I'd like the appropriate body part to show like this:
I can achieve this using 2 options:
UIBuzierPath class to draw, but would take a lot of trial and error and many overlapping shapes per body part to get fitting nicely as similiar in a previous question: Create clickable body diagram with Swift (iOS)
Crop out the highlighted body parts from the original image and position it over the UIImageView depending on which UIButton selected. However there would only be one image per body part, but still less cumbersome then option 1.
Now, my question is not HOW to do it, but which would be a BETTER option for achieving this in terms of cpu processing and memory allocation?
In other words, I'm just concerned about my app lagging as well as taking up app size storage. I'm not concerned about how much time it takes to do it, I want to just make sure my app doesn't stutter when it tries to draw all the shapes.
Thanks.
It is very very very unlikely that either of those approaches would have any significant impact on CPU or memory. Particularly if in option 2, you just use the alpha channels of the cutout images and make them semitransparent tinted overlays. CPU/GPU-wise, neither of the approaches would drop you below the max screen refresh rate of 60fps (which is how users would notice a performance problem). Memory-wise, loading a dozen bezier paths or single-channel images into RAM should be a drop in the bucket compared to what you have available, particularly on any iOS device released in the last 5 years unless it's the Apple Watch.
Keep in mind that "premature optimization is the root of all evil". Unless you have seen performance issues or have good reason to believe they would exist, your time is probably better spent on other concerns like making the code more readable, concise, reusable, etc. See this brief section in Wikipedia on "When to Optimize": https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize
Xcode have tests functionality built in(and performance tests too), so the best way is to try both methods for one body part and compare the results.
You may find the second method to be a bit slower, but not enough to be noticed by the user and at the same time a lot more easier to implement.
For quick start on tests here.
Performance tests here.
I am taking a stab at John Conway's game of life [wiki] & [demo]. I have developed a small program in C to calculate the next state - using a 1D array (but with 2D array logic).
I am hoping to make a small iOS app out of this (to Objective-C!), and am wondering the best and fastest way to render a grid like seen in the video. Note, it would have to render every fraction of a second and would use an array of 1's and 0's to determine a "block's" respective colour.
Edit: I'm probably looking at around 10 frames/sec, but a very large grid. It'd be rendering out hundreds of thousands of squares. Of course, if this isn't physically possible with iPhone/iPad technology then I'll reduce the grid size. It is variable without issue, just looks more 'epic' on a grand scale.
Any suggestions will help out, never touched anything of this manner before.
The best way depends on your criteria. Fastest would probably be to use OpenGL. You might even be able to write a shader to do the entire simulation. However, OpenGL is hard. Really hard.
I suspect that using Core Graphics and implementing code in a view's drawRect method that renders the array of cells onto the screen would be fast enough. It depends on how many cells you have and how many frames/second you want to draw.
I have a collection view that displays 3 images, two labels, and 1 attributed string(strings are of different colors and font sizes and values are not unique for every cell). One of the images is coming from the web and I used AFnetworking to do the downloading and caching. The collection view displays 15 cells simultaneously.
When I scroll I can only achieve 25 frames/sec.
Below are the things I did:
-Processing of data were done ahead and cached to objects
-Image and views are opaque
-Cells and views are reused
I have done all the optimizations I know but I can't achieve at least 55 frames/sec.
If you could share other techniques to speed up the re-use of cells.
I was even thinking of pre-rendering the subviews off screen and cache it somewhere but I am not sure how it is done.
When I run the app on the iPhone it is fast since it only shows at least four cells at a time.
The first thing you need to do is fire up instruments and find out if you're CPU-bound (computation or regular I/O is a bottleneck) or GPU-bound (the graphics card is struggling). . depending on which of these is the issue the solution varies.
Here's a video tutorial that shows how to do this (among other things) . . This one is from Sean Woodhouse # Itty Bitty Apps (they make the fine Reveal tool).
NB: In the context of performance tuning we usually talk about being I/O bound or CPU bound as separate concerns, however I've grouped them together here meaning "due to either slow computation or I/O data is not getting to the graphics card fast enough". . if this is indeed the problem, then the next step is to find out whether it is indeed related to waiting on I/O or the CPU is maxed-out.
Instruments can be really confusing at first, but the above videos helped me to harness its power.
And here's another great tutorial from Anthony Egerton.
What is the size of the image that you use?
One of the optimization technique which would work is that
Resize the image so that it matches the size of the view you are displaying.
I asked a similar question here a while ago about boosting the speed at which MKOverlays are added to an MKMapView by using threading during their creation, but I soon realized that the part of the process that was really dragging me down was not the creation of the overlays, but their addition to the map. Creating many overlays (even 3000+) takes an acceptable amount of time, but adding them all to the map takes far too long (15 seconds).
I know 'what are your favorite' questions usually aren't considered 'right' for Stack Overflow, but I think this question is okay because although it is subjective in a way, there is still a 'right' answer- the one that provides significant changes in the performance of an MKMapView with lots of MKOverlayViews.
Basically, I'd love to know if anyone has any tips or tricks (any at all) for tuning the speed of the addition of many different MKOverlays to a map view. Right now my alternative is combining them all into one big line, which is much faster, but then I lose the ability to treat each segment as an individual line (i.e. being able to show a callout for each segment), which is one of the cooler features in the app, so I'd really like to find a way to make this work. Right now, all of the lines load, given enough time, but even after, scrolling is a nightmare.
I'd really like to hear your thoughts! Thanks!