As an Android developer I've been moving away from Eclipse to Intellij IDEA for production code in anticipation of Google's Android studios which shares a code base with IDEA.
My experience has been a good one up to this point. I've only been using IDEA at the office, where I have a 4x core Intel i7 machine running Ubuntu 12.04 LTS (Sun JDK/JRE), up to this point and I've never noticed what the performance of IDEA really is.
Now however after setting IDEA up on my personal computer at home the performance is abysmal. Memory usage is normal, but the constant CPU usage bounces between 80%-100% (over the whole application lifecycle). And that is when nothing else is running on the machine and no work is being done, by me or visually by the IDE.
This makes IDEA unusable when working on it, and I can forget about having anything else running along side it.
My home specs and software are:
Intel Core 2 duo 3GHz
8 GB RAM
Ubuntu 12.04 x64 LTS (3.8.0-35-generic) running of SSD SATA
Intellij IDEA 13.0-0ubuntu1 build: IC-133.193
Tried both OpenJDK and Sun
And the strange thing is that this happens as well with Android Studios.
All help in trying to debug this behaviour would be appreciated.
#Edit 1:
Noticed that the CPU load falls down to 20% when bringing up dialogs (Project structure, Settings, etc) and then goes right back up when dismissing them.
#Edit 2:
I tested simply getting the tarball straight from JetBrains, instead of using the one in Canonical's ppa. The performance was significantly better for at least an hour (20-30% CPU usage while idle). Seems that the native file watcher in C-PPA wasn't working properly and was indexing the whole filesystem.
However the performance became worse after the first hour or so, going back to 90-100% CPU.
The issue turned out to be the native-file watcher being out-of-date. IntelliJ was re indexing my whole drive it seems. Was fixed by uninstalling the version gotten from Canonical's ppa and installing directly from JetBrain's own webpage.
Are you using any plugins outside of the included ones which might cause issues.
I don't run Ubuntu anymore but can't recall any issues with high CPU-usage when i did. (I use Fedora with KDE a colleague uses Fedora with GNOME though. )
Does this always happen or only when you have a project open?
I'm thinking if this might have something to do with the background-compile that IDEA does.
Might be worth trying to turn this off.
Found under Project Settings -> Compiler -> Make Project Automatically
worst case it is a Unity-integration issue or something. Haven't used unity so can't say.
Usualy I manage to fix it by deleting IDE's index files rm -rf ~/.RubyMine60/system,
don't forget to change .RubyMine60 to IDEA's config folder
If you're willing to do some sleuthing, you could run the Oracle JVM and use the VisualVM profiler to see where the IDE is spending all its time, presuming it's a Java-based process that's actually eating your CPU cycles.
Related
My app is having tearing problems when I scroll fast horizontally. Normally I'd just enable vsync, but I don't know how to do that in Qt. The tearing is occurring on my dev PC which runs Linux with a X-server, but it will also need to work well on the target system which is either Android or Linux+EGLFS.
One google result was from the Qt4 era and said that the tearing will be gone in Qt 5. But apparently it isn't.
Many google results are about env vars for embedded linux systems, such as QT_QPA_EGLFS_FORCEVSYNC, but I'd prefer the solution to work for my dev PC as well.
One google result said that vsync being enabled/disabled depends on the renderloop in use. I don't override the renderloop, so, since I'm on linux, I think I'm using the threaded renderloop.
Here's a bugreport about nvidia binary drivers causing this.
https://bugreports.qt.io/browse/QTBUG-45480
I too am using those drivers, so this may be it - just a driver bug. If so, at least it's unlikely to happen on my target hardware (I still haven't tested there), so that's good.
I have a TurboX Laptop with AMD E-1800 APU with 4GB RAM, I use it for development purposes, but the CPU is not working well, i have installed ubuntu 16.04 amd64 on it. Whenever i load more than two tabs in chromium it gets more slower,even gets more worst while working in IDEs. Cant afford new one right now. Any suggestions about some lightweight linux distros to work on development and with easy package installation like lamp, Android Studio and NetBeans etc.
Good morning my friend,
I think that the major problem here is your hardware.
In every distro it will be slow with so less RAM and an unpowerfull CPU like that.
Although, you can try Lubuntu or Puppy and see if your situation will get improved.
BR,
Loukas
I have a project and the files are on Guest OS (Red Hat Enterprise Linux) with Virtualbox, my host OS is Mac OS. I used to coding right in RHEL with editor Atom. But my boss told me that it's inefficient to code in a Guest OS, well, it makes sense because Mac OS or Windows is more responsive than linux, so I changed my way:
Copy the whole project located on RHEL to a share folder between Mac OS and RHEL using rsync
Code with Atom in Mac OS
Copy back the project in share folder to the original project in RHEL by rsync
I'm using Atom (not vim in RHEL) because it can edit the whole project in one window which is convenient for my situation. But there is a problem: after copying back the project in Step 3, git status shows everything has been changed even though I just edited only a few files. That is a little annoying.
Is there any better way to code in such environment? any advice is appreciated.
BretzL's suggestion to use shared folders is a good one, but I think it's important to address the underlying issue: your boss' assumption about coding being inefficient or slow just because you're working on a VM is simply not true.
It sounds like your new workflow, which was instituted as a result of his/her advice, is causing you to have a harder time developing that you did on the VM. The shared folders will help with that, but if you have the VM configured to have access to enough cores and memory, then its performance for most tasks will be fine, and there may not be any problem with developing on the VM directly. I do a significant amount of development on a VM, and haven't had any issues. You may experience slower builds on the VM if you're building whole kernels or other large projects, but if that's not the case, it should be fine.
If you didn't have any performance or productivity problems before forcing yourself to work outside of the VM, then... it wasn't a problem.
(I also have an issue with the assumption that Linux is always less responsive than Windows or Mac OS, but that's a debate for a different day.)
VirtualBox supports shared folders, so you dont need to rsync back and forth. Just mount the shared folder into where your application server on RHEL guest expects the code.
I also recommend you take a look at https://www.vagrantup.com/ for managing developer VMs.
Using NDK r8c, Eclipse 4.2, Windows 7 64
I've used remote debuggers before (on other platforms, via gigabit ethernet) for large C++ codebases that felt no different than local debugging. The Java debugger that comes with the SDK runs fast too. Therefore I'm quite baffled why gdb is so slow to connect and step over lines of code.
In my current application, which is around 20 static libraries and 1500 source files, it takes about 15 seconds to connect, and about 2 seconds to step. I'm more concerned about stepping.
Has anyone ever profiled gdb to see what the problem is? If so, any suggestions?
I have. My cohorts and I at NVIDIA have contributed several commits to AOSP to address this problem, although our focus has been on shared libraries (symbol load performance, and pending symbol resolution.) We have sped up solib load processing by a factor of 6x. (Although, after doing our own work we discovered that 3x of that 6x had already been solved upstream by GNU, in 7.5... so we abandoned our reinvention, and submitted the relevant 7.5 patches up to Google's NDK repository, which was based on the older 7.3 GDB.) I believe all of our speedups are present in r8d... but I haven't checked.
I cannot think of any reason why static libraries would slow things down, but I must admit I haven't given any thought to them. Do you have a specific reason for believing so, or was that just comment to give perspective about the size and scope of your debugging needs?
We have begun to work on the stepping problem, but don't have anything to share yet. Basically, the bottleneck is ADB (especially on Windows.) Additionally, there is a lot of chatty communication between GDB and gdbserver, when stepping, especially if you are using an IDE with local window, register window, expression window, stack window, etc., all updating with each step. That's a lot of chatter that could likely be optimized for the IDE use-case.
Just some of the fixes that we are considering for speeding up stepping will be IDE-specific:
Using python scripting to pre-process watch expressions in GDB, rather than in the IDE.
Implementing "super-packets" communicating between GDB and gdbserver... packets that encapsulate IDE-specific communications in a way that minimizes chatter between GDB and gdbserver.
We intend to share all of this with the Android community.
I'm looking for a really really small linux distribution or process of making my own that's sole purpose is to get an air application to launch full screen and stay there; Essentially I'm building a home kitchen computer that runs entirely as an AIR app.
I have looked into using windows xp; and windows xp embedded but they pose so many issues I figured I'd try modern linux.
I have also seen TinyCore Linux which looks interestingly small but not sure what issues that poses in regards to running AIR and "hardware" accelerated display. I've also thought about stripping down an Ubuntu installation but I'm sure somebody must have done this already; google is just failing me right now...
I'm also interested in running an "embedded" version of say android and running the air app on some arm-based hardware again; with just the AIR runtimes only - although this is less preferred as it's more complex.
I'm also hooking this up to a touch screen monitor (not yet arrived) so I'll need to hunt down or write some drivers for translating the touch events into something AIR can understand... (this was my main intention for using windows in that all the drivers will just work).
What I'm after
Minified Linux kernel with JUST the drivers for the box I need
X Display with accelerated graphics support (Doesn't have to be X if AIR can run on a frame buffer?)
Running a Full screen AIR application (simple enough)
Ability to write back to the filesystem (enough support for AIR)
SSH Access for remote control
Samba for updating the filesystem (easier to maintain the system)
Touch screen support (3M Ex III I think...)
Audio support
Don't need
Don't need any window manager or any other GUI tools unless required by AIR
Don't need any toolbars or file managers or anything; The AIR app is the "OS"
Don't need any package managers or repos
Don't need multi user or logging in; everything can just run as an unprivileged account
Don't need to
I don't mind hand crafting the filesystem and configs if that makes it easier; I'm mainly looking for a "filesystem" that is as tiny as possible that I can just plop my AIR app into and write some scripts to get it to start when the X server starts
Thanks,
Chris
Try an embedded Linux build system such as Buildroot. It can build an entire system from source, and be very lightweight. The basic system is less than 1 MB in size.
Ended up going with Tiny Core. Very tiny and quick to boot up. You can also write extensions for it and you don't have a persistent drive which allows you to just switch the thing off without worry that it's going to break something -- exactly what you need in a kitchen :-D.
My current plan is to:
Just set up a working version using Ubuntu as this is mostly supported by Adobe
Slowly strip it back and try and get as little things to start as possible on boot
Try building my own distro/package from source and selecting only the packages I need
Compile my own kernel with nearly everything turned off and just leave on the things I need