I have an issue where when I run my application in debug mode, the application shows obvious runtime lags. As specified in numerous articles, the application bundle will run up to 10X faster than when running from xcode (including with instruments).
However, when I open the app (going through the project explorer/products/app_name.app) and show in finder then run the app, several features that work perfectly in debug mode (in my case, certain keyboard press functions).
The app runs much faster as expected than the debug mode runtime, but lacks some of the behaviors which work in debug mode. Furthermore, some other actions close the application altogether.
I don't know where to start figuring this out but have some intuition and would like confirmation what it might be:
1-Instruments: is there a difference of memory usage between debug and application bundle for which debug keeps a cap on memory usage, CPU usage etc?
2- COnsidering cache misses, is it possible that my nSResponder when I activate a key does not catch some later down the track switch cases, which will create a cache miss? (I doubt this since my controls file runs as an extension to one of my main loops). Note: If this works fine in debug mode, why would it not work in the application itself?
Any pointer to why this behavior greatly appreciated, so that I don't make large changes that won't affect the outcome (It's a large project).
So are you saying that when you compile for debugging (-ONone), then things work. But when you compile for release then some things don't work?
Try unchecking 'Enable backtrace recording' in the Options tab of the Run scheme action.
Related
I'm building a flutter app in VsCode
When am ready to lunch my app
I use Run -> start debugging in vsCose
But alternatively I can use Run -> Run without debugging
So what the difference between the two?
In Debug mode, you can pause your application at so called break points. This can help you to find bugs in your code. You can also figure out, which values your variables consist at a speficic part in your application.
You can set a break point by double clicking on the left of a line number where you want to pause your code from running (see here: debug break point example)
Debug mode is for development. As such, the binaries are larger and slower, because they have e.g. the names of all your functions stored alongside line number information for debug tracing to work. Hot reloading is also an important feature of development or debug mode.
When you run in production mode, all the debug information is stripped away, the app loads much faster, and all debug information is elided from the binary that is produced. It is for end-use.
start debugging mean's in debug mode, it is best when you want to debug your app. you can set multiple break points and check what is value of that variable at particular point of time.
Run without debugging mean simple run where your break points doesn’t matter.
Moreinfo: https://flutter.dev/docs/development/tools/vs-code
When running my code in debug mode, I keep getting 2 error messages:
Could not delete [path_to]\productiondb.log. May be locked by another process
I don't know what process might be locking it. It comes when I make changes to the code while my Pivotal tc Server is running in debug mode, but it dosent seem to create a lot's of trouble. Sometimes however, I get this warning:
Also due to some changes. I usally just restart the server and move on. This isen't the real problem, the real problem is that I get these messages when I havent doen any changes. Somethimes it accures when I run a certen part of the code, other times i occurs when I open certen codes in sts, however, it doen't seem to stop at the same place twice.
I am suspecting that this has something to do with git. I am using git to change between versions and doing tests. So I am thinking that STS has some of the code in memory from before I changed branche with git, and isen't updating it before I run or open the file with that code. But I am rather new to both sts and git, and can't be certan that it would work that way. If it is, does anyone know how to update sts after I have changed branch? If it is not, does anyone know what might causing it?
If you run an app in debug mode, the Eclipse Debugger tells the application when code gets changed and tries to use the debug API to swap in the new code into the running application. This is especially useful if you debug your code, hit a breakpoint, step through the code, fit the issue, change the code, and press save. At that moment, the Eclipse compiler updates the class file and tells the running JVM to swap in the new code. If that succeeds, the debugger will jump back to the last stack frame and the execution of your app will continue with the beginning of the method that you entered. This allows you to directly continue to debug and step through the updated code without restarting the app.
While this is a great feature of the JVM, it is very limited in terms of what scope of changes to the classes the JVM can deal with while doing this hot-swap. It is usually limited to method implementations. So adding new methods, adding or deleting members of the class, etc, are not supported. As a result, the above screenshot will appear. It means that the JVM wasn't able to hot-swap the changed code and will continue to run with the previously loaded code instead of the changed one.
My app runs really slow with Xcode 4.5, and i just realized it's due the debugger always on.
It seems you can't select NONE under Manage Schema/Release/Debugger, so how can you disable debugger on Xcode 4.5?
many thanks in advance
It is unlikely that the slowness is due to the debugger being attached. It is more likely that the slowness is due to compiling in Debug rather than Release mode. Debug does not optimize the code. Release does. You can switch your configuration to Release and it should speed up, but be more difficult to debug. You can create separate Debug and Release schemes if you like.
Note that the specific difference in Debug and Release that matters here is the compiler optimization. Debug passes "-O0". Release passes "-Os". You could of course create a Debug configuration that passes "-Os" without changing other things (like turning off assertions, if your Release configuration does that).
I've read in so many places that code-splitting can significantly speed up the initial loading time of a GWT application.
However, before we do the splitting, we would like to know whether the deferred download of codes also work when in development mode?
Currently our most painful point is that in development mode with debug mode, when we refresh the browser (to refresh the changes in client code) it will take 3.7 years for the app to reload.
In production mode the application will load in a matter of seconds.
Code splitting has absolutely no effect in Dev Mode, because your application is not compiled to JavaScript.
When GWT.isScript() is false (Dev Mode) RunAsyncCallback.onSuccess() method is run immediately. It is apparent if you inspect the source code of the GWT.runAsync() method.
EDIT: just a small thing to add as well: do NOT use Chrome with DevMode. Chrome still has an outstanding bug (the link escapes me right now) that makes the DevMode Plugin for Chrome run really slowly. Use Firefox, it is the fastest with the Dev Mode plugin.
As said before code splitting has absolutely no effect in Dev Mode.
Only thing that I could suggest you is to increase memory for jvm on start:
For example we use in our project:
-Xmx1024m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:PermSize=256M -XX:MaxPermSize=512M
Also upgrade your working hardware(CPU, memory), it's could help you to compile faster your java code on Dev mode.
If you want faster DevMode you should be more careful with how you write your application. User lazy loading where possible, split app into standalone modules.
E.g. let's say you have some app with 5000 classes. And usually a developer needs to change only some part of application, not all application (one page for example). So basically you need to make sure that to start one simple part of app, only classes needed by the app are loaded. E.g. instead of loading 5000 classes only 100 will be loaded. Also check for common errors like RPC Type Explosion, they affect devmode as well. And try GWT 2.4 it is much faster than previous versions (I mean DevMode).
In my (medium length) experience I noticed Internet Explorer 9 is also pretty fast in Dev Mode, and a lot more stable than Chrome. The GWT plug-in doesn't crash every other reload of the application.
You could give it a try, see if it works better for you.
Ok
SO recently I've being having a lot of trouble with an application working in debug mode but not working in distribution mode.
Is it possible to use xcode debugging tools such as break points and variable tracing with an adhoc distribution build of an app?
If it's not how would one usually go about debugging such a thing?
Assuming that your crash logs aren't giving you any clues (you'll need to hook up to the device to get them) there are lots of things you can do.
But I'd start by looking at the crash logs ... the clues will be there and don't forget Apple make distribution crash logs available to you through iTunesConnect.
1) Copious logging is one thing. Lots of developers use a switch so that in debug, logs go to the console but for other builds they are dropped. Consider a different option where you log to a file instead. You could then push the log files to a remote server for debugging. It's a bit of a slog to set this all up, but once you've done it, you'll wonder how you ever lived without it.
2) Another option is to use Flurry and log events when you detect that things have gone wrong. This can cover more controlled problems when things aren't as expected rather than random crashes. This can be a useful feature for released apps provided your terms and conditions are clear about what data you are logging and why.
3) Make sure you do a clean build, I'm sure you've already done this, but sometimes it clears these issues.
4) Are you using external libraries / modules? I've come across issues with older versions of TT where the arm6/7 build settings were wrong and this was causing issues for distribution builds. Basically check through the build settings for each profile and make sure it is what you expect.
5) Suspect a race condition. In distribution mode (often because the logging is turned off) you will find that your application runs a little bit faster. That can reveal timing issue bugs in badly written code.
So yes ... there is a lot you can do ... you just can't attach the debugger ;-)
Not possible to debug an application in distribution mode.
The build configuration difference between Distribution, Debug, and Release is really whatever parameters you have set for that in XCode. If your Distribution config is giving you problems and the release isn't, the easiest way to fix it is to go back through Apple's steps on copying the Release config and making the changes to make it a Distribution config, like you did originally.
The alternative is to go through every line of the configurations for Release and Distribution and find what's different. The other way is a LOT faster. :)