Is there any way (tool, library, etc.) to log all the actionscript function calls at runtime in a SWF created from Flash Professional? I often inherit projects, and want to more easily analyze and understand their operation. Profiling be nice too.
Logging all calls will probably not help much, because if there are many "small" items involved (i.e. cells in a list, nodes in a tree, particles in a particle engine, enemies in a game, etc. etc.) the log files will clutter up with repetition and soon grow to a size where the sheer amount of information will make learning about the functionality a slow, tedious and painful task.
It is more useful to use a profiler to manage dependencies, memory etc., and use a debugger to step through the code, and/or set breakpoints at interesting points and navigate deeper into the architecture from there.
FDT has a great profiler and debugger. And as a free tool, Monster Debugger is quite good.
You can try Show method entry and Show method exit in SWFWire Debugger. It also offers some profiling. You can also track object creation and destruction, and memory usage.
Disclaimer: I wrote this app
Related
In our large code base, I could find there are multiple cudaStreamCreate() functions. However, I could not find cudaStreamDestroy() anywhere. Is it important to destroy streams after program is complete or one does not need to worry about this? What is a good programming practice in this regard?
Is it important to destroy streams after program is complete or one does not need to worry about this?
The runtime API will clean up all resources allocated (streams, memory, events, etc) by the context owned by the process during normal process termination. It isn't necessary to explicitly destroy streams in most situations.
While talonmies answer is correct, it is still often important to destroy your streams, and other entities created in CUDA:
If you're writing a library - you may finish your work well before the application exits. (Although in that case you might be working in a different CUDA context, and maybe you'll simply destroy the whole context).
If your code which creates streams might be called many times.
also, if you don't synchronize your streams after completing all work on them, then you might be missing some errors (and the results of your last bits of work); and if you do have a "last synch", that often means an opportunity to also destroy the stream.
Finally, if you use C++-flavored wrappers, like mine, then streams get destroyed when you leave the scope in which they were created, and you don't have to worry about it (but you pay the overhead of stream destruction API calls).
CUDA 10 added runtime API calls for putting streams (= queues) in "capture mode", so that instead of executing, they are returned in a "graph". These graphs can then be made to actually execute, or they can be cloned.
But what is the rationale behind this feature? Isn't it unlikely to execute the same "graph" twice? After all, even if you do run the "same code", at least the data is different, i.e. the parameters the kernels take likely change. Or - am I missing something?
PS - I skimmed this slide deck, but still didn't get it.
My experience with graphs is indeed that they are not so mutable. You can change the parameters with 'cudaGraphHostNodeSetParams', but in order for the change of parameters to take effect, I had to rebuild the graph executable with 'cudaGraphInstantiate'. This call takes so long that any gain of using graphs is lost (in my case). Setting the parameters only worked for me when I build the graph manually. When getting the graph through stream capture, I was not able to set the parameters of the nodes as you do not have the node pointers. You would think the call 'cudaGraphGetNodes' on a stream captured graph would return you the nodes. But the node pointer returned was NULL for me even though the 'numNodes' variable had the correct number. The documentation explicitly mentions this as a possibility but fails to explain why.
Task graphs are quite mutable.
There are API calls for changing/setting the parameters of task graph nodes of various kinds, so one can use a task graph as a template, so that instead of enqueueing the individual nodes before every execution, one changes the parameters of every node before every execution (and perhaps not all nodes actually need their parameters changed).
For example, See the documentation for cudaGraphHostNodeGetParams and cudaGraphHostNodeSetParams.
Another useful feature is the concurrent kernel executions. Under manual mode, one can add nodes in the graph with dependencies. It will explore the concurrency automatically using multiple streams. The feature itself is not new but make it automatic becomes useful for certain applications.
When training a deep learning model it happens often to re-run the same set of kernels in the same order but with updated data. Also, I would expect Cuda to do optimizations by knowing statically what will be the next kernels. We can imagine that Cuda can fetch more instructions or adapt its scheduling strategy when knowing the whole graph.
CUDA Graphs is trying to solve the problem that in the presence of too many small kernel invocations, you see quite some time spent on the CPU dispatching work for the GPU (overhead).
It allows you to trade resources (time, memory, etc.) to construct a graph of kernels that you can use a single invocation from the CPU instead of doing multiple invocations. If you don't have enough invocations, or your algorithm is different each time, then it won't worth it to build a graph.
This works really well for anything iterative that uses the same computation underneath (e.g., algorithms that need to converge to something) and it's pretty prominent in a lot of applications that are great for GPUs (e.g., think of the Jacobi method).
You are not going to see great results if you have an algorithm that you invoke once or if your kernels are big; in that case the CPU invocation overhead is not your bottleneck. A succinct explanation of when you need it exists in the Getting Started with CUDA Graphs.
Where task graph based paradigms shine though is when you define your program as tasks with dependencies between them. You give a lot of flexibility to the driver / scheduler / hardware to do scheduling itself without much fine-tuning from the developer's part. There's a reason why we have been spending years exploring the ideas of dataflow programming in HPC.
when our flash game is in scene A, the memory is stable about 800M(it loads almost all the role animations and role skill animations). But when toggle to scene B, the memory keep increasing to 1400M in one minute. I have watched the explorer and make sure it doesn't load any resource when the memory is increasing. And when I repeat it, the memory increase to 2000M and the explorer freeze, the page crashed.
So what may cause such heary memory leak in short time? I haven't met such problem before, any help will be appreciated.
The question is not giving enough concrete information on what you're doing and thus it's hard to precisely what you' doing wrong.
But there are ways to deal with these situations:
Install Adobe Scout (http://gaming.adobe.com/technologies/scout/). This is a really good profiling tool to help you see what's going on in your app.
Enable telemetry data in your app. There are settings for that in both Flash Professional and Flash Builder. If you don't know how to enable it, please search the web since it's very well explained.
Run your app and look at Scout's panels to see what is happening and how the much memory, at what time you're allocating.
Other than that there are hundreds of reasons why the memory leaks. Just look at your code and understand when you call what and use profiling tools to know where to look.
If using FlashBuilder you can run the profiler to try and track down memory leaks and watch how many instances are being created. There are other profiling tools out there if you are using another type of IDE.
If using flash professional you can check out this link Profiling tools in flash builder to improve the performance of flash professional projects
After some days's work, we finally find out the problem.
Before I ask the question, I have tried Scout and Profile but not work(because the problem not occurs). I guess only bitmapdata draw or copypixels functon was called in an infinite loop or in a enterframe event handler could such quick and big memory leak.
Then we found out how to repeat the problem in luckļ¼ it really makes it much easier to solve the problem.
So here is the procedure we solve the problem after we could repeat the problem.
run the game in profile, and take a memory snapshot.
repeat the problem, after the memory increase a lot, take a memory snapshot.
find the loitering objects between the memory snapshot.
At last, the problem is an function was called in each frame when one skill appers. And in the function a bitmapdata was used to draw the role animation
I am making racing game in Libgdx.My game apk size is 9.92 mb and I am using four texture packer of total size is 9.92 Mb. My game is running on desktop but its run on android device very slow. What is reason behind it?
There are few loopholes which we neglect while programming.
Desktop processors are way more powerful so the game may run smoothly on Desktop but may slow on mobile Device.
Here are some key notes which you should follow for optimum game flow:
No I/O operations in render method.
Avoid creating Objects in Render Method.
Objects must be reused (for instance if your game have 1000 platforms but on current screen you can display only 3, than instead of making 1000 objects make 5 or 6 and reuse them). You can use Pool class provided by LibGdx for object pooling.
Try to load only those assets which are necessary to show on current screen.
Try to check your logcat if the Garbage collector is called. If so than try to use finalize method of object class to find which class object are collected as garbage and try to improve on it.
Good luck.
I've got some additional tips for improving performance:
Try to minimize texture bindings (or generally bindings when you're making a 3D game for example) in you render loop. Use texture atlases and try to use one texture after binding as often as possible, before binding another texture unit.
Don't display things that are not in the frustum/viewport. Calculate first if the drawn object can even be seen by the active camera or not. If it's not seen, just don't load it onto your GPU when rendering!
Don't use spritebatch.begin() or spritebatch.end() too often in the render loop, because every time you begin/end it, it's flushed and loaded onto the GPU for rendering its stuff.
Do NOT load assets while rendering, except you're doing it once in another thread.
The latest versions of libgdx also provide a GLProfiler where you can measure how many draw calls, texture bindings, vertices, etc. you have per frame. I'd strongly recommend this since there always can be situations where you would not expect an overhead of memory/computational usage.
Use libgdx Poolable (interface) objects and Pool for pooling objects and minimizing the time for object creation, since the creation of objects might cause tiny but noticable stutterings in your game-render loop
By the way, without any additional information, no one's going to give you a good or precise answer. If you think it's not worth it to write enough text or information for your question, why should it be worth it to answer it?
To really understand why your game is running slow you need to profile your application.
There are free tools avaiable for this.
On Desktop you can use VisualVM.
On Android you can use Android Monitor.
With profiling you will find excatly which methods are taking up the most time.
A likely cause of slowdowns is texture binding. Do you switch between different pages of packed textures often? Try to draw everything from one page before switching to another page.
The answer is likely a little more that just "Computer fast; phone slow". Rather, it's important to note that your computer Java VM is likely Oracles very nicely optimized JVM while your phone's Java VM is likely Dalvik, which, to say nothing else of its performance, does not have the same optimizations for object creation and management.
As others have said, libGDX provides a Pool class for just this reason. Take a look here: https://github.com/libgdx/libgdx/wiki/Memory-management
One very important thing in LibGDX is that you should make sure that sometimes loading assets from the memory cannot go in the render() method. Make sure that you are loading the assets in the right times and they are not coming in the render method.
Another very important thing is that try to calculate your math and make it independent of the render in the sense that your next frame should not wait for calculations to happen...!
These are the major 2 things i encountered when I was making the Snake game Tutorial.
Thanks,
Abhijeet.
One thing I have found, is that drawing is laggy. This means that if you are drawing offscreen items, then it uses a lot of useless resources. If you just check if they are onscreen before drawing, then your performance improves by a lot surprisingly.
Points to ponder (From personal experience)
DO NOT keep calling a function,in render method, that updates something like time,score on HUD (Make these updates only when required eg when score increases ONLY then update score etc)
Make calls IF specific (Make updations on certain condition, not all the time)
eg. Calling/updating in render method at 60FPS - means you update time 60 times a sec when it just needs to be updated once per sec )
These points will effect hugely on performance (thumbs up)
You need to check the your Image size of the game.If your image size are more than decrease the size of images by using the following link "http://tinypng.org/".
It will be help you.
I saw System.gc() somewhere on the internet today and I wanted to know if it is or isn't recommended to use in a Flash CS5 project and why.
In every garbage-collected system I know of, the garbage collection machinery was designed to run in the background as an abstraction the programmer should theoretically pay no attention to. There are some special situations where forcing a collection is useful, but these usually involve interrupts (real machine interrupts, not actionscript events), testing/debugging scenarios, or some tricky latency management necessities. Odds are you will never need to call System.gc() and you can safely ignore it.
System.gc() is only available in the debugger version of Flash Player and some AIR applications. Calling it on a normal website, under a normal Flash Player will have no effect whatsoever and will silently fail.
System.gc() is designed only for testing purposes.
System.gc() is only for testing purposes. It can be handy to monitor the memory usage your application is using and call System.gc() in order to highlight the possibility of any memory leaks.
Tip: As far as I remember you have to call System.gc() twice to force it to collect immediately.
The documentation states that this method only works in a debug player.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/System.html#gc()
So, to summarise, if you're testing memory, it's quite handy, otherwise don't use it.