Почему C быстрее Java (с точки зрения Java-разработчика)

>Однако быстродействие нужно далеко не во всех областях программирования, иногда важна скорость разработки, стоимость поддержки, и.т.д.

Это-то очевидно, я больше о том, что сейчас высокоуровневые трансляторы позволяют сэкономить и скорость разработки, и скорость выполнения. Ну или близко к тому.

вы сейчас в плену мифов.

Компилятор не может действительно эффективно, так что бы в 100 раз быстрее, использовать SSE инструкции.

Всё дело в том, что действительно эффективное использование этих инструкций возможно тогда, когда программист понимает, что он пишет код не под абстрактный x86, а под SSE модуль, который накладывает другие требования на организацию данных в памяти.

Компилятор не может развернуть ваши структуры данных из row based в column based, что бы получить нужное ускорение.

Так что увы и ах, но «ассемблерные вставки», а точнее просто вызовы крайне специализированных функций до сих пор остаются возможностью именно человека.

Да почти любое приложение на Swing кроссплатформенно. На StackOverflow также обсуждался вопрос, как собирать приложения на SWT, чтобы зависимости от разных платформ встраивать в JAR, чтобы тоже запускать «где угодно»(на платформах, под которые есть реализация SWT).

Клиент Промсвязьбанка :)
Если правильно помню еще IntelliJ IDEA, но при чем здесь GUI приложения?

Java, как платформа, реально снимает кучу проблем с совместимостью и кросплатформенностью.
Т.е. если окружение уже есть, то совсем не хочется озадачиваться вопросом «как же запустить здесь бинарник?», даже если в теории git работает несколько быстрее JGit.

Черепаха хороша, даже при разработке в Eclipse предпочитаю её, а не плагин EGit (ибо порой глючит при Merge/Push), но некоторые вещи (по сути мелочи, но всё же) вызывают полное недоумение. Банальнейший пример: переключиться с ветки на ветку.
Черепаха: клик — TortoiseGit — Switch to… — появляется диалог, где в комбобоксе нужно выбрать ветку — нажать ОК. Вопрос: почему бы сразу не сделать менюшку со списком веток?
Ибо в EGit это: клик — Team — Switch to… — выбраь ветку прямо в меню. И всё.
Мелочь — а раздражает %)

Я не берусь точно говорить, что именно сыграло роль в данном случае, но аргументы обычно такие:

1) Если я не ошибаюсь — для Git, в отличие от SVN, не предусмотрено готовой библиотеки имеющией 'нормальное' API. Плагин для SVN (Subclipse) к Eclipse как раз использует нативные библиотеки, как основной вариант (но можно переключиться на использование pure java имплементации).
Сценарий интеграции с внешними утилитами через запуск исполняемого файла и считывание его потоков вывода всегда менее удобно и надежно, чем работа через полноценое API. У тому же накладывает ряд органичений. Разработчики всегда избегают данного варианта, если имеется такая возможность.

2) При наличии библиотеки ее лицензия может быть не совместима с лицензией продукта для которой пишется плагин (вроде бы это не наш случай).

3) Как уже отмечали выше — гарантировать, что плагин для Eclipse будет работать на всех платформах, на которых будет работать сам Eclipse.

Таким образом создание JGit дало два значимых плюса:

1) Создание более удобного и главное — надежного способа работы с ним.

2) Избавление пользователя от необходимости ставить Git, так как это может быть не совсем тривиально — как в случае с windows. Ведь в случае ошибки при установке бочку будут катить на плагин и на то, как сложно с ним работать.

Из минусов реимплементации Git — гланым является то, что работает он немного не так как оригинальный. Я наталкивался на небольшие отличия при мерже веток и отслеживании истории переименованых файлов. Но это мелочи, которыми можно пренебречь. Плюсы JGit, в виде удобной и экономящей время библиотеки для java разработчиков, — перевешивают все эти незначительные минусы.

Не уверен, что любой «нативный» компилятор, да ещё с отключенной оптимизацией выдаст код, работающий быстрее JIT.

А что делать, если из-за одного гвоздя строительство целого дома останавливается? Тратить пару месяцев на осваивание «ентерпрайзного» молотка? А заказчик дома не против, чтоб я гвоздь отверткой забивал, хотя и предупрежден, что дверь будет не так быстро открываться, как могла бы, а может и вобще заклинить.

>Тогда первое, это касается только массивов из примитивных типов?
Любой массив наследует Object

>И второе, почему же использование int[5] тогда лучше использования byte[20]?
Если честно — не знаю, возможно JIT разворачивает маленькие массивы в переменные. Для 5 это происходит а для 20 нет. Это лишь предположение, было бы интересно узнать реальную причину.

Речь идет не о int[5]. Имеется в виду замена

class GitObject {
    Data someData;
    byte[] digest;
}

на

class GitObject {
    Data someData;
    int digest0;
    int digest1;
    int digest2;
    int digest3;
    int digest4;
}

Т.е. заинлайнить SHA1-дайджест прямо в поля класса. Отсюда экономия на лишнем объекте byte[] и ссылке на него.