форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Взгляд на производительность JavaScript от одного из разрабо..."	+/–
Сообщение от opennews (ok) on 17-Июл-13, 21:04
Шай Альмог (Shai Almog), один из разработчиков виртуальной машины и JIT-движка для Java, опубликовал (http://www.codenameone.com/3/post/2013/07/why-mobile-web-is-...) развёрнутый ответ на недавнюю публикацию (https://www.opennet.ru/opennews/art.shtml?num=37421) Дрю Кроуфорда о проблемах JavaScript, мешающих использованию данного языка для создания мобильных приложений. По мнению Шая причина низкой производительности web-приложений в основном связана с особенностью интерфейса DOM (http://ru.wikipedia.org/wiki/Document_Object_Model) (Document Object Model), а не самим языком. Кроме того, высказанные в статье претензии к  сборщику мусора и JIT-компилятору, по мнению Шая, являются ошибочными. В своей заметке Шай проводит достаточно много аналогий с Java и, в частности, приводит пример достижения приемлемой производительности Java Mobile на телефонах Nokia с экраном 240x320 и 2 Мб ОЗУ. URL: http://www.codenameone.com/3/post/2013/07/why-mobile-web-is-... Новость: https://www.opennet.ru/opennews/art.shtml?num=37442
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
Сообщение от Аноным (ok) on 17-Июл-13, 21:04
Будем делать интерфейсы на канвансе и ВебГЛ.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Взгляд на производительность JavaScript от одного из разрабо..."	+7 +/–
	Сообщение от Наивный чукотский юноша on 17-Июл-13, 21:07
	Ох, /me предчувствует, что слова анонима пророческие.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	10. "Взгляд на производительность JavaScript от одного из разрабо..."	–7 +/–
	Сообщение от Аноним (??) on 17-Июл-13, 21:45
	Под канвас и вебгл и для десктопов-то нет нормальных гуй-библиотек. Разве что квадратные кнопочки в блендере. Если описывать полноценный DOM-аналог для канваса на js - он будет тормозит намного больше чем сам DOM Что же до тормозов DOM'а. Так сравнивать-то его не с чем. Возможности разметки на HTML+CSS+js куда значительнее любого GUI на любом языке
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	13. "Взгляд на производительность JavaScript от одного из разрабо..."	+5 +/–
	Сообщение от Sergey (??) on 17-Июл-13, 22:15
	>> Возможности разметки на HTML+CSS+js куда значительнее любого GUI на любом языке Ляпнул так ляпнул...
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	14. "Взгляд на производительность JavaScript от одного из разрабо..."	–1 +/–
	Сообщение от Sinot (ok) on 17-Июл-13, 22:20
	У меня даже была шальная мысль попробовать нарисовать веб-приложение (даже не так, приложение в браузере) целиком на канве, но подумал о производительности и сразу охота отпала. Хотя вроде как Qt и GTK именно так и делают.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	21. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Карбофос (ok) on 17-Июл-13, 23:04
	на Qt3 было достаточно много проблем с отрисовкой, очень многое из проблемного списка было улучшено в Qt4. Но, довольно часто были траблы, когда похабно сделанный signal-slot механизм в исходном коде программы списывался на кривость Qt. Такое видел очень часто.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	24. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Crazy Alex (ok) on 17-Июл-13, 23:37
	Для канвы хотя бы в принципе есть шанс получить приличное быстродействие, выкинув все что можно в видеокарту, оставив браузеру самый минимум. А с монструозным DOM - ни шанса, так еще и приходится втискиваться в идиотскую браузерную потоковую модель.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	43. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 18-Июл-13, 02:36
	Да, кстати, работа с DOM самое тормозное, пожалуй.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	18. "Взгляд на производительность JavaScript от одного из разрабо..."	–2 +/–
	Сообщение от Аноним (??) on 17-Июл-13, 23:02
	Возразить нечего, я так понимаю?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	25. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Crazy Alex (ok) on 17-Июл-13, 23:39
	Фишка в том, что для ПРИЛОЖЕНИЯ 99% этих возможностей либо избыточны, либо вообще вредны. А ресурсы на них тратить всё равно приходится. А примитивная и довольно симпатичная кнопочка жила еще в DOS на каком-нибудь 286.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	35. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
	Сообщение от Аноним (??) on 18-Июл-13, 01:40
	Представь себе что на всех сайтах есть только набор сереньких GUI-компонент и больше ничего
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	38. "Взгляд на производительность JavaScript от одного из разрабо..."	+5 +/–
	Сообщение от Crazy Alex (ok) on 18-Июл-13, 01:52
	Для веб-приложения - именно это и нужно.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	45. "Взгляд на производительность JavaScript от одного из..."	+7 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 07:20
	> Представь себе что на всех сайтах есть только набор сереньких GUI-компонент и > больше ничего это было бы просто великолепно. а то МегаДизайнеры задолбали.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	68. "Взгляд на производительность JavaScript от одного из..."	–1 +/–
	Сообщение от Аноним (??) on 18-Июл-13, 17:12
	>> Представь себе что на всех сайтах есть только набор сереньких GUI-компонент и >> больше ничего > это было бы просто великолепно. а то МегаДизайнеры задолбали. Linx в зубы. Что-то не слишком-то ты бежишь в голом текстике на мордокнижечке сидеть, а, арису?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	75. "Взгляд на производительность JavaScript от одного из..."	+2 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 17:28
	> Linx в зубы. Что-то не слишком-то ты бежишь в голом текстике на > мордокнижечке сидеть, а, арису? прикинь, я и в графичке туда не бегу. я понимаю, что ты жизни не представляешь без соцсетей, но я — к счастью — не ты.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	54. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Vkni (ok) on 18-Июл-13, 09:05
	> Представь себе что на всех сайтах есть только набор сереньких GUI-компонент и > больше ничего Ну почему же обязательно серенькие? Можно и синие. :-) Красивые кнопочки можно отрисовать с любыми ресурсами - это же задача художника. Скажем, многие художники вообще в бинарной палитре работали - гравюры делали. И великолепно получалось. :-) Есть ряд вполне приятно отрисованных интерфейсов, сделанных в условиях жутких ресурсов - OpenLook, NEXTStep. Да даже MacOS в чёрно-белом варианте не так плоха.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	58. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Пышпер on 18-Июл-13, 09:38
	> Можно и синие Еретик!
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	69. "Взгляд на производительность JavaScript от одного из разрабо..."	–1 +/–
	Сообщение от Аноним (??) on 18-Июл-13, 17:12
	>> Можно и синие > Еретик! Трепло он, а не еретик.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	36. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 18-Июл-13, 01:43
	На хабре народ в печали что флеш погубили, с его анимированными векторными мувиклипами.. А на опеннете предлагают довольствоваться стандартными визуальными компонентами..
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	39. "Взгляд на производительность JavaScript от одного из разрабо..."	+4 +/–
	Сообщение от Crazy Alex (ok) on 18-Июл-13, 01:53
	Они там вообще красивости много больше любят, чем функциональность.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	7. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 17-Июл-13, 21:38
	Так уже. http://www.zebkit.org/samples/index.html
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	12. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
	Сообщение от Карбофос (ok) on 17-Июл-13, 22:10
	так криворукие программисты и на нём умудрятся сделать так, чтобы работало медленно. ибо у оных принцип: кое-как работает - не трогай. от этого все проблемы гурьбой потом внезапно появляются. здесь на 5% потери производительности забили, там - еще столько же. никто ж не знает, что такое профилировка, етить.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Взгляд на производительность JavaScript от одного из разрабо..."	–1 +/–
Сообщение от all_glory_to_the_hypnotoad (ok) on 17-Июл-13, 21:08
> В своей заметке Шай проводит достаточно много аналогий с Java и, в частности, приводит пример достижения приемлемой производительности Java Mobile на телефонах Nokia с экраном 240x320 и 2 Мб ОЗУ. там то GC скрее всего не было и мб даже самого JITа. Тормозить было особо нечему
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 17-Июл-13, 21:42
	>там то GC скрее всего не было Как же? Ведь память надо как-то освобождать. Не в ручную же. >мб даже самого JITа мало какие телефоны умели jit.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	17. "Взгляд на производительность JavaScript от одного из разрабо..."	–1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 17-Июл-13, 23:01
	> Как же? Ведь память надо как-то освобождать. Не в ручную же. там gc совсем простой, чуть ли не аналог сишного malloc()/free() или в лучшем случае питоновского GC со ссылками, который освобождает объект сразу как только можно. GC в яве тормозит именно из-за отложенного коллектора, сначала засирает что только можно, а потом наступает пц.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	28. "Взгляд на производительность JavaScript от одного из разрабо..."	–1 +/–
	Сообщение от Magister on 17-Июл-13, 23:42
	> там gc совсем простой, чуть ли не аналог сишного malloc()/free() или в лучшем случае > питоновского GC со ссылками, который освобождает объект сразу как только можно. GC в яве > тормозит именно из-за отложенного коллектора, сначала засирает что только можно, а потом > наступает пц. Не такой и простой, по крайней мере на сонериках db2010 и выше. Помню, как ручками вызывал System.gc() чтобы памяти чуть освободить когда она нужна. Так что он, естественно, проще, чем на десктопе - но засирает что только можно ни капли не хуже.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	32. "Взгляд на производительность JavaScript от одного из разрабо..."	–11 +/–
	Сообщение от iZEN (ok) on 18-Июл-13, 00:02
	> GC в яве тормозит именно из-за отложенного коллектора, сначала > засирает что только можно, а потом наступает пц. Ну а кто, спрашивается, насоздаёт короткоживущих объектов на "каждый чих", а потом не знает как их повторно использовать и надеется на уборку мусора? Правильно — бывшие программеры C/C++, которым привычные malloc()/free() использовать тут не дали, а всучили убогий "ручник" сломанного "стопкрана" System.gc(). :)))
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	33. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
	Сообщение от Карбофос (ok) on 18-Июл-13, 00:22
	проверка твоих теоретических умозаключений: сделай парсер, или какой обработчик строк на жабе. будешь сильно удивлён. вот уж во истину, на каждый чих. даже, если соединяешь с константными строками. просто пичалька, от "глубинных" знаний жабакодеров. и да, как обычно, в своём упорно не замечеют бревна. такая грусть.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	64. "Взгляд на производительность JavaScript от одного из разрабо..."	–3 +/–
	Сообщение от iZEN (ok) on 18-Июл-13, 14:24
	> проверка твоих теоретических умозаключений: сделай парсер, или какой обработчик строк > на жабе. будешь сильно удивлён. вот уж во истину, на каждый > чих. даже, если соединяешь с константными строками. > просто пичалька, от "глубинных" знаний жабакодеров. и да, как обычно, в своём > упорно не замечеют бревна. такая грусть. Для простейшей операции конкатенации строк в Java (и J2ME) используется оптимизация на уровне компилятора — там, где это возможно и программист специально не извратился (а такое сплошь и рядом случается с обезьянками, которые лучше всех знают что и как), используется практически во всех случаях подстановка класса для работы со строками java.lang.StringBuffer. Это хорошо видно в декомпилируемом классе и в показаниях профилировщика. Если вы не умеете пользоваться декомпилятором в Java и профилировщиком кода, то продолжайте дальше нести чушь про теоретические умозаключения и соринки в наших глазах.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	66. "Взгляд на производительность JavaScript от одного из разрабо..."	+4 +/–
	Сообщение от Карбофос (ok) on 18-Июл-13, 14:52
	ты это серьезно? декомпайлер для жабы, он такой ужасно сложный, прям аж жуть. как раз я и занимался разбором полётов подобных парсеров, логгеров, в том числе и видел, каким образом жабисты извращаются, дабы ускорить процесс обработки строк. так что можешь продолжать и дальше детский лепет на лужайке. раскрою тебе даже большой секрет, до которого ты никак не можешь допиликать сам: именно из-за геморра с объектами из-за каждого выпука невозможно сделать адекватно работающий, не тормозящий браузер. это как пример. Sun в свое время по этим же причинам не захотела конвертировать OpenOffice, а IBM свои большие проекты тестирует сначала на джаве, а потом уже конверитует их по своему усмотрению в фортран, плюсы и другие языки.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	34. "Взгляд на производительность JavaScript от одного из разрабо..."	+2 +/–
	Сообщение от Аноним (??) on 18-Июл-13, 00:37
	Какой смысл писать на жабе, если всё равно приходится изворачиваться кренделем ради памяти?
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	65. "Взгляд на производительность JavaScript от одного из разрабо..."	–3 +/–
	Сообщение от iZEN (ok) on 18-Июл-13, 14:28
	> Какой смысл писать на жабе, если всё равно приходится изворачиваться кренделем ради памяти? Потому что память в Java — не ресурс. Если его реально не хватает, то повышайте скилл Re-Usable Objects и/или докупайте модули памяти. Третьего не дано.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	71. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 18-Июл-13, 17:14
	>> Какой смысл писать на жабе, если всё равно приходится изворачиваться кренделем ради памяти? > Потому что память в Java — не ресурс. Если его реально не > хватает, то повышайте скилл Re-Usable Objects и/или докупайте модули памяти. Третьего > не дано. Ачо, сборщики мусора еще не изобрели? Или их вызов - песдетс ракетная наука?
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	81. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 17:34
	ну чего ты пристал: изя же рукожоп. а у рукожопа «докупайте памяти, она копейки стоит» — любимый «аргумент».
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	84. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Карбофос (ok) on 18-Июл-13, 18:11
	>Третьего не дано. ой ли?! портировать программу из жабы на более подходящий для задачи язык программирования.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	86. "Взгляд на производительность JavaScript от одного из разрабо..."	–3 +/–
	Сообщение от iZEN (ok) on 18-Июл-13, 18:17
	>>Третьего не дано. > ой ли?! портировать программу из жабы на более подходящий для задачи язык программирования. Портируйте Spring Framework на что-то другое — поговорим. Напишите NetBeans, Eclipse, IDEA на чём-то другом — обсудим. Что, кишка тонка и рвётся от малейшего пука?
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	88. "Взгляд на производительность JavaScript от одного из..."	+2 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 18:41
	это да: таких тормозных удолбищ, как eclipse, например — ещё поискать. авторы Qt на это всё посмотрели — и сделали QtCreator. а если уж говорить про «кишки», изенька, то один emacs все ваши жабоподелки уделывает влёт.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	90. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Карбофос (ok) on 18-Июл-13, 19:16
	если бы этим проектам не было бы адекватной альтернативы, их бы давно уже портировали. а для меня лично, так я не хочу, чтобы какой-то IDE откушивал под 2 гига памяти. не могу себе позволить, т.к. на работе в основном память под виртуалки уходит, для тестирования, а дома для моих проектов старенького лептопа хватает, на котором только 2 гига памяти. и ничего, для браузера, кедов и KDevelop хватает и в своп не лезет. прикинь?
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	99. "Взгляд на производительность JavaScript от одного из разрабо..."	–2 +/–
	Сообщение от iZEN (ok) on 19-Июл-13, 07:41
	У меня SWAP'а вообще нету и не жужжу. 8 ГБ, ZFS — полёт нормальный.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	102. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 19-Июл-13, 09:24
	> и не жужжу единственное полезное дело, которое ты мог бы совершать, и то…
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	106. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
	Сообщение от Карбофос (ok) on 19-Июл-13, 10:03
	и что? предмет гордости, или предлагаешь мне на моём домашнем лептопе с двумя гигами своп вырубить и тоже начать гордиться?
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	108. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 19-Июл-13, 10:04
	> и что? предмет гордости, или предлагаешь мне на моём домашнем лептопе с > двумя гигами своп вырубить и тоже начать гордиться? можешь не вырубать, а просто писать, что вырубил и гордиться. вон изя же сидит в винде, а бсдой ему это гордиться не мешает.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	109. "Взгляд на производительность JavaScript от одного из разрабо..."	–4 +/–
	Сообщение от iZEN (ok) on 19-Июл-13, 12:51
	> и что? предмет гордости, или предлагаешь мне на моём домашнем лептопе с > двумя гигами своп вырубить и тоже начать гордиться? Ни для кого не секрет, что SWAP придуман для того, чтобы "эмулировать" дополнительный объём оперативной памяти, когда приобрести модули ОЗУ выходит очень дорого или невозможно в принципе — конструктивно или ещё по каким-либо причинам. Плата за это — низкая скорость обмена данными с более медленными устройствами (HDD, SSD), чем микросхемы ОЗУ. Гордится тем, что у тебя есть SWAP такого же объёма, что и оперативка (2 ГБ), незачем. Это констатирует лишь то, что задачам вполне хватает выделенного объёма оперативной памяти, а в какую-то часть времени приходится мириться с тормозами и замедлением ответной реакции системы. Ежели SWAP создан для того, что так советуют умудрённые опытом специалисты в учебниках 1990-х годов по организации виртуальной памяти, то гордиться "задним умом" забавно.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	112. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
	Сообщение от труляляй on 20-Июл-13, 00:24
	изька, зачем ты тут рассказываешь про своп? тебе больше рассказать нечего?
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	113. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
	Сообщение от Карбофос (ok) on 21-Июл-13, 20:41
	кто тебе сказал вообще, что я использую своп такого же объема, что оперативка? ты часто показываешь примитивность своего мышления. что наводит на мысли про "задний ум" относятся к тебе, а не ко мне.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	44. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 18-Июл-13, 02:42
	> Правильно — бывшие программеры C/C++, которым привычные malloc()/free() использовать > тут не дали, а всучили убогий "ручник" сломанного "стопкрана" System.gc(). :))) Вообще-то если что, emscripten для повышения производительности JS зарубает GC к черту. Знаешь как?   1) Он выделяет себе невь...й массив. 2) В него заворачиваются все malloc(). 3) GC вообще в пролете - он это не сколлектит вплоть до самого конца работы программы. И вот только так emscripten умудряется нормальную скорость работы получить. Послав GC нафиг. Совсем.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	47. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 07:24
	> Ну а кто, спрашивается, насоздаёт короткоживущих объектов на «каждый чих», а потом > не знает как их повторно использовать и надеется на уборку мусора? так кто же виноват, что в жабе сборщик настолько хреновый? (хотя, конечно, он там не один, и не хреновые они, просто пишут на жабе вот такие вот изи — и получается говно).
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	72. "Взгляд на производительность JavaScript от одного из..."	+2 +/–
	Сообщение от Аноним (??) on 18-Июл-13, 17:17
	>> Ну а кто, спрашивается, насоздаёт короткоживущих объектов на «каждый чих», а потом >> не знает как их повторно использовать и надеется на уборку мусора? > так кто же виноват, что в жабе сборщик настолько хреновый? > (хотя, конечно, он там не один, и не хреновые они, просто пишут > на жабе вот такие вот изи — и получается г о в н о). Х р е н о в ы й не сборщик. Х р е н о в ы е рукосуи, которые пишут программы. Каждый дятел.... Приведу один пример. Я несколько лет назад видел прикладу, разработанную на BPEL - слыхал? - которая за 7 минут работы после рестарта сервера на линухе умудрялась скушать 14 (!) Гб оперативы и сдохнуть. Почему? Потому что программер (в данном контексте слово означает сексуальную ориентацию) Костя Шакалов не знал, что надо вызывать сборщик мусора (один из трех, имеющихся в наличии, кстати говоря) и не посчитал это необходимым - при таком изобилии свежести^Wпамяти всего в двух калориях^Wтирах системы. Ачо, плашка памяти ж как лопата дерьма стоит, фуле! Память - не ресурс!
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	76. "Взгляд на производительность JavaScript от одного из..."	–1 +/–
	Сообщение от Аноним (??) on 18-Июл-13, 17:30
	> Шакалов не знал, что надо вызывать сборщик мусора (один из трех, > имеющихся в наличии, кстати говоря) А еще говорят что на си программировать сложно, память выделять/освобождать, блаблабла. А у самих вон сколько гемора. И память совсем не утекает :)
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	77. "Взгляд на производительность JavaScript от одного из..."	+2 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 17:31
	если сборщик мусора надо явно вызывать — это не язык, а дерьмо. впрочем, практика показывает, что если в названии чего-то софтового есть «bussines» — то это дерьмо с вероятностью, близкой к единице.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	52. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 18-Июл-13, 08:04
	Вы хоть Макконнелла почитайте для общего развития, что ли, прежде, чем чушь пороть. Программы пишутся - в том числе и для людей, а не только для машин. Короткая жизнь объёкта - это во многом то, что борется с кашей в голове. А то, что жаба это переваривает с трудом - так это проблема жабы и её мусорки.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	55. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Vkni (ok) on 18-Июл-13, 09:08
	> А то, что жаба > это переваривает с трудом - так это проблема жабы и её > мусорки. Там нет выделения на стеке, прекрасно приспособленного для короткоживущих объектов.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	56. "Взгляд на производительность JavaScript от одного из..."	+/–
	Сообщение от arisu (ok) on 18-Июл-13, 09:14
	> Там нет выделения на стеке, прекрасно приспособленного для короткоживущих объектов. что, в принципе, решается хитрым generational gc. стек тянет за собой толстый и невкусный механизм unwinding'а, а generational gc позволяет не загромождать VM всякой бесполезной фигнёй. одно дело, когда у меня try/catch/finally явно в коде стоит, и unwind frames создаются только для такого кода. и совсем другое — когда создаются везде, где меня угораздило создать локальный автоматический объект.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	59. "Взгляд на производительность JavaScript от одного из..."	+/–
	Сообщение от Vkni (ok) on 18-Июл-13, 09:55
	Твой нелюбимый Куздра об этом недостатке Java как-то рассказывал, но где - не помню.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	60. "Взгляд на производительность JavaScript от одного из..."	+/–
	Сообщение от arisu (ok) on 18-Июл-13, 10:12
	> Твой нелюбимый Куздра об этом недостатке Java как-то рассказывал, но где — > не помню. этому товарищу доверие нулевое вообще, он феерически некомпетентен. проверять каждое его утверждение на предмет «а где он в этот раз накосячил» — мне откровенно лень.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	57. "Взгляд на производительность JavaScript от одного из..."	+/–
	Сообщение от arisu (ok) on 18-Июл-13, 09:18
	p.s. другое дело, что для GC неплохо бы иметь несколько больше помощи от MMU, чем сейчас предоставляется через API, но это уже совсем другая песня. ребята из Azul Systems, например, показали, что при некоторой поддержке GC становится сильно легче жить.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	73. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 18-Июл-13, 17:18
	> Вы хоть Макконнелла почитайте для общего развития, что ли, прежде, чем чушь > пороть. Программы пишутся - в том числе и для людей, а > не только для машин. Короткая жизнь объёкта - это во многом > то, что борется с кашей в голове. А то, что жаба > это переваривает с трудом - так это проблема жабы и её > мусорки. Еще раз - это проблема не среды. Это проблема п и д о р а^Wп р о г р а м м и с т о в.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	78. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
	Сообщение от Аноним (??) on 18-Июл-13, 17:32
	> Еще раз - это проблема не среды. Это проблема п и д > о р а^Wп р о г р а м м и с т о в. Проблема только в том что сферическая среда в вакууме - ни о чем. А на яве, да и на JS обычно пишут ... изены всякие. Нет, парочка специалистов по рокетсайнсу на всю планету и на яве могут нормально писать. Остальные на ней пишут "как изен".
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	91. "Взгляд на производительность JavaScript от одного из разрабо..."	–2 +/–
	Сообщение от iZEN (ok) on 18-Июл-13, 19:19
	> Остальные на ней пишут "как изен". Смеёшься что ли? Я привёл прямо противоположную историю о тех бывших C/C++ программистах, которые привыкли на каждый чих делать malloc()/free() в своих "сишечках", а потом пересели на Java с розовой надеждой на автоматику управления жизненным циклом объектов. С таким отношением, естественно, скоро наступает песец и большое удивление на тему "куда это подевалась свободная память?!". Лихорадочно начинают дёргать ручник сломанного стоп-крана System.gc() в надежде на то, что JVM за них приберёт ИХ_ЖЕ мусор, который они бездумно наплодили в циклах и связали с долгоживущими объектами кучей ссылок. Ага — щаз.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	93. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
	Сообщение от Карбофос (ok) on 18-Июл-13, 19:56
	> о тех бывших C/C++ программистах, которые привыкли на каждый чих делать malloc()/free() в своих "сишечках", а потом пересели на Java с розовой надеждой на автоматику управления жизненным циклом объектов. какая-то невероятно неправдоподобная история. есть такая вещь, называется "сила привычки", так вот, если это действительно не жопорукие кодеры, то они бы и на джаве продолжали бы использовать подобные механизмы, как malloc/free: вызывать деструкторы объектов, когда они уже не нужны. в общем, нестыковка какая-то, нонсенс. сам историю выдумал?
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	94. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 19:58
	> сам историю выдумал? а то. изя же говнокодер, причём говнокодер, который не знает ни одного языка нормально. иначе до него бы дошло, что те, кто «постоянно дёргают» — никак не могли наплодить якорей на автоматические объекты, потому что привычка чистить перед free() вырабатывается потом, кровью и болью. и потому такой программер на автомате вместо free() писал бы '= null' какое-нибудь.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	95. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от Карбофос (ok) on 18-Июл-13, 20:04
	>привычка чистить перед free() вырабатывается потом, кровью и болью так вот об чем и речь. или, может это джава так пагубно влияет, что люди явно дегенерировать начинают :-D
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	96. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 20:12
	да нет, я изю много лет знаю (думаю, больше десяти), и не только по этому ресурсу. тут дело такое: он сначала был дурак, а потом увлёкся жавой. а не наоборот. :3
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	98. "Взгляд на производительность JavaScript от одного из..."	+/–
	Сообщение от Карбофос (ok) on 18-Июл-13, 22:46
	не, я не про него, а про его полёт фантазии, в которой бывшие программисты сей и плюсей дружно понадеялись на мегакрутую фичу жабы - автоматический мусоросборщик.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	101. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 19-Июл-13, 09:23
	есть подозрение, что это отголоски его личного неприятного опыта.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

4. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
Сообщение от Аноним (??) on 17-Июл-13, 21:28
Одно лучше другого, Лучше бы что то типа Dart увидеть прям в ядре браузера
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 17-Июл-13, 21:29
	http://www.dartlang.org/ http://golang.org/
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 17-Июл-13, 21:30
	> Одно лучше другого, > Лучше бы что то типа Dart увидеть прям в ядре браузера Фичи дарта тут https://docs.google.com/presentation/d/1zfucLA3XNqRb7W56ldU_...
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	37. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Xasd (ok) on 18-Июл-13, 01:46
	> https://docs.google.com/presentation/d/1zfucLA3XNqRb7W56ldU_... SIMD это хорошо, но... ...нет необходимости менять синтаксис языка ЛИШЬ ТОЛЬКО для того чтобы добавить туда SIMD это можно реализовать -- даже и с существующим синтаксисом ECMAScript: https://github.com/johnmccutchan/ecmascript_simd/blob/master... http://wiki.ecmascript.org/doku.php?id=strawman:simd_number
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	40. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 18-Июл-13, 02:17
	>> это можно реализовать -- даже и с существующим синтаксисом ECMAScript: спасибо но костыли не нужны совершенно для скачки хлама
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	8. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
	Сообщение от Аноним (??) on 17-Июл-13, 21:40
	Лучше бы родили стандарт байткода для generic web browser vm. Не смогли договориться об интерфейсах в различных аппаратно-софтенных платформах, отрыгните хотя бы для браузеров. Нет, млин, будем костылять через конверторы c/c++ в js, лить эту беду по http и хвастаться какой у нас реализован расклиздатый jit
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	15. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Sinot (ok) on 17-Июл-13, 22:23
	> Лучше бы родили стандарт байткода для generic web browser vm. Так вроде NaCl оно и есть, правда пока только у Google и не стандарт.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	16. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 17-Июл-13, 22:28
	Похоже что оно. Вива ля Гугл?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	19. "Взгляд на производительность JavaScript от одного из разрабо..."	–1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 17-Июл-13, 23:02
	нет, это совсем не оно. NaCl это нативный код.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	26. "Взгляд на производительность JavaScript от одного из разрабо..."	–1 +/–
	Сообщение от Crazy Alex (ok) on 17-Июл-13, 23:41
	Они PNaCl допилили, там именно байткод. Да и какая разница, байткод или натив - лишь бы были стандартные соглашения по вызовам.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	49. "Взгляд на производительность JavaScript от одного из..."	+/–
	Сообщение от arisu (ok) on 18-Июл-13, 07:26
	> Да и какая разница, байткод или натив …всё равно кроме x86 процессоров нет!
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	61. "Взгляд на производительность JavaScript от одного из..."	+/–
	Сообщение от мшефд on 18-Июл-13, 10:41
	_P_NaCl - уже LLVM.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	62. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 10:55
	> _P_NaCl — уже LLVM. я рад за него. а за тебя — нет: ты не умеешь читать то, на что отвечаешь.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	41. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
	Сообщение от Xasd (ok) on 18-Июл-13, 02:17
	>> Лучше бы родили стандарт байткода для generic web browser vm. > Так вроде NaCl оно и есть, правда пока только у Google и > не стандарт. NaCL/PNaCl ---- это <embed>-сущность ну не могут быть <embed>-сущности быть даже близко быть в стандарте. слишком уж кривая задумка!! более вероятно что вообще <embed>-тэг (и <object>-тэг) ВЫПИЛЮТ из стандарта! :) Asm.Js ---- является намного более безкостыльное решение чем NaCL/PNaCl .
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	50. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 07:27
	> Asm.Js ---- является намного более безкостыльное решение чем NaCL/PNaCl . ага. примерно такое же хорошее, как твой русский.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	42. "Взгляд на производительность JavaScript от одного из разрабо..."	+2 +/–
	Сообщение от Xasd (ok) on 18-Июл-13, 02:24
	> Нет, млин, будем костылять через конверторы c/c++ в js, ну сколько уже раз повторять блин ----- Asm.Js -- НЕ ЯВЛЯЕТСЯ Яваскриптом!!! из него НЕЛЬЗЯ получить: ни доступа к объектам Document-Object-Model ни доступа даже к динамечески выделяемой памяти и сборщику мусора. (ды и вообще объектов-ни-каких нет в Asm.Js, там только байты, и манипуляция с байтами..) всё взаимодействие с внешним миром -- в выполяемом модуле Asm.Js -- происходит либо через FFI-интерфейс либо через общую бинарную память!.. ЭТО ДАЖЕ БЛИЗКО НЕ ПОХОЖЕ НА JAVASCRIPT!!! Asm.Js даёт свободы -- даже меньше чем даёт свободы уровень языка Си! это уже реально почти ассемблер!! (есть же люди которые называют язык Си -- кросплатформенным ассемблером?! а Asm.Js ещё более низкоуровневый язык чем язык Си!) (FFI --- "Foreign Function Interface") <sarcasm>...но выже блин такие умные, вы даже не читая спецификаци (и не написав ни одного скрипта с использование Asm.Js) уже всё знаете</sarcasm> попробуйте напишите на asm.js -- HelloWorld -- который оперирует с массивами данных и оперирует с указателями на функции --- и тогда поймёте настолько Asm.Js похож/или/не_похож на Javascript . ...ну например --- напишите модуль сортировки (таким образом: будут использованы массивы) с выбором алгоритма сортировки (таким образом: будут использованы указатели на функции). или напишите модуль AES-шифрования. (в этом случае тоже можно задействовать массивы и указатели на функции). чего вам терять? вот прям щаз сядьте и напишите!
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	51. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 07:29
	откуда такая истерика-то? я читал предварительные спеки этих мегакостылей ещё до того, как тебе в новостях о них рассказали. родилось мегакостылями и осталось мегакостылями. по сравнению с этим даже си выглядит верхом изящества.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	70. "Взгляд на производительность JavaScript от одного из..."	+/–
	Сообщение от Xasd (ok) on 18-Июл-13, 17:14
	> по сравнению с этим даже си выглядит верхом изящества. ну логочни что ЯП Си сделан для того чтобы на нём писали люди. а ASM.JS сделан для того чтобы в него компилировали из Emscripten (а НЕ для того чтобы напрямую на ASM.JS что-то писали люди!). > а НЕ для того чтобы напрямую на ASM.JS что-то писали люди! если эта фраза не понятна для тебя -- то повторяю: напиши хоть что-то вручную (без Emscripten) на ASM.JS и поймёшь почему я так говорю. ASM.JS ---- это по сути лишь просто обычный байткод, но записынный в текстовом виде, а не в бинарном виде. > откуда такая истерика-то? оттуда что пишут на форумах ерись, называя Asm.Js ---- Яваскриптом, или костылём. ************************************************************ разработчики ASM.JS могли бы запросто сделать чтобы код на ASM.JS был-бы в бинарном виде, а не в текстовом виде как щаз. ...но если бы они так сделали -- то это не увеличело бы производительность выполнения (а увеличело бы производительность лишь её инициализации). однако Emscripten в таком случае должен бы был генерировать двойной результат: на Javascript и в бинарном виде ----- И ЭТО БЫЛО БЫ ОЙ КАК ГЛУПО!!
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	79. "Взгляд на производительность JavaScript от одного из..."	+/–
	Сообщение от arisu (ok) on 18-Июл-13, 17:32
	вот почему как защитник очередных костылей — так даже человеческим языком, на котором пытается писать свою «защиту», и то не владеет нормально, а?
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	80. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 18-Июл-13, 17:32
	> Лучше бы родили стандарт байткода для generic web browser vm. Дык LLVM есть. PnaCL. Но что-то мне кажется что не договрятся.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	83. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 17:37
	>> Лучше бы родили стандарт байткода для generic web browser vm. > Дык LLVM есть. PnaCL. Но что-то мне кажется что не договрятся. неа. он у LLVM неудобный для написания интерпретаторов. и не очень удобный для трансляции слабо типизированых языков с GC. поэтому LLVM можно использовать как одну из реализаций VM, но завязывать всё на него — неудобно.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

22. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
Сообщение от Аноним (??) on 17-Июл-13, 23:19
Хоть кого то осенило, что недостаточно просто разрабатывать мощное железо чтобы была производительность надо еще и правильно его программировать. А то сейчас часто так: Что то программа тормозит, ай ладно напишу системные требования выше и проблема решена.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Взгляд на производительность JavaScript от одного из разрабо..."	+4 +/–
	Сообщение от Crazy Alex (ok) on 17-Июл-13, 23:42
	Что забавно - осенило одного из людей, стоявших у истоков этой веселой тенденции забивания на качество софта.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

23. "Взгляд на производительность JavaScript от одного из разрабо..."	–3 +/–
Сообщение от anoname on 17-Июл-13, 23:30
Слоупок у слоупока украл слоупока.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "Взгляд на производительность JavaScript от одного из разрабо..."	+2 +/–
Сообщение от Dimon (??) on 17-Июл-13, 23:46
пля он сравнивает JavaME и JavaScript
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
Сообщение от Dimon (??) on 17-Июл-13, 23:49
че мелочится и городить, OpenJDK  интегрируем в браузер и делов то.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	53. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 18-Июл-13, 08:27
	Java апплетам в браузере сто лет в обед.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

31. "Взгляд на производительность JavaScript от одного из разрабо..."	–2 +/–
Сообщение от iZEN (ok) on 17-Июл-13, 23:55
> приводит пример достижения приемлемой производительности Java Mobile на телефонах Nokia с экраном 240x320 и 2 Мб ОЗУ. J2ME работала в основном в AOT-окружении, с предварительной прекомпиляцией байткода, так как для полноценного JIT нужно довольно много дорогой на мобильных устройствах оперативной памяти.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

63. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
Сообщение от kb on 18-Июл-13, 11:11
> Clarification update: For some reason people read this as a rebuttal of Drew Crawford article, it is not. It is merely a response, I accept almost everything he said but have a slightly different interpretation on some of the points.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

67. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
Сообщение от Adblog (ok) on 18-Июл-13, 17:03
Недавно делали реализацию алгоритма RSA-шифрования на JS. Все правильно пишут - JS адский тормоз, на нем нереально добиться нормальной производительности. Впрочем и Java - жуткий тормоз ...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	74. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 18-Июл-13, 17:20
	> Недавно делали реализацию алгоритма RSA-шифрования на JS. Все правильно пишут - JS > адский тормоз, на нем нереально добиться нормальной производительности. Впрочем и Java > - жуткий тормоз ... Не бывает тормознутых систем. Тормоза бывают лишь между ушей у прокладки между сиденьем и консолью (С) Я
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	82. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
	Сообщение от Аноним (??) on 18-Июл-13, 17:34
	> Не бывает тормознутых систем. Тормоза бывают лишь между ушей у прокладки между > сиденьем и консолью (С) Я Ну да, конечно, только вот почему-то во всяких там кодеках и криптографии до сих пор юзают максимально оптимизированный вручную ассемблер с распоследними наборами команд. Потому что в разы быстрее работает, если горячий кусок так выписать.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	85. "Взгляд на производительность JavaScript от одного из разрабо..."	–1 +/–
	Сообщение от iZEN (ok) on 18-Июл-13, 18:15
	>> Не бывает тормознутых систем. Тормоза бывают лишь между ушей у прокладки между >> сиденьем и консолью (С) Я > Ну да, конечно, только вот почему-то во всяких там кодеках и криптографии > до сих пор юзают максимально оптимизированный вручную ассемблер с распоследними наборами > команд. Потому что в разы быстрее работает, если горячий кусок так > выписать. Ещё можно вспомнить апплеты "банк-клиент", которые почему-то не используют ассемблер (вот ведь странно), а юзающие алгоритмы на Java.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	89. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 18-Июл-13, 18:42
	чем меньше вспоминать банковский софт — тем лучше. а то там и ActiveX были, помнится. тоже мне, вершина технологий.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	100. "Взгляд на производительность JavaScript от одного из..."	–1 +/–
	Сообщение от iZEN (ok) on 19-Июл-13, 07:45
	> чем меньше вспоминать банковский софт — тем лучше. а то там и > ActiveX были, помнится. тоже мне, вершина технологий. Увлекался COM-объектами? :)) Я тоже в своё время, но быстро понял угрёбищность этого.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	103. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 19-Июл-13, 09:25
	изя, ты себе остаток мозга повредил?
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	105. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от Карбофос (ok) on 19-Июл-13, 09:56
	мдя. вообще-то, на сколько я понял, подразумевалось совсем другое. раньше светились с завидным постоянством в новостях проблемы с безопасностью ActiveX. причем, некоторые дыры не закрывались месяцами. кто читал в своё время эти новости, тот знает, что ActiveX - одна большая дырень, спроектированная без какого-либо концепта безопасности ПО.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	107. "Взгляд на производительность JavaScript от одного из..."	+1 +/–
	Сообщение от arisu (ok) on 19-Июл-13, 10:03
	а какая может быть вообще с ActiveX безопасность, если там даже песочницы не предусмотрено изначально? а учитывая, что в XP юзер ещё и локальный администратор… заходи кто хочешь, бери что надо. жабка хоть изначально в песочницу посажена (пусть в песочнице и находят дырки, но тем не менее). что, как я выше писал, не мешало банкам вовсю ActiveX использовать (а кое-кто, по слухам, и до сих пор…). и я намекал на то, что «а банки используют» — вообще никакой не аргумент и ничего не доказывает.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

87. "Взгляд на производительность JavaScript от одного из разрабо..."	+1 +/–
Сообщение от Аноним (??) on 18-Июл-13, 18:39
Ну да, по сравнению с джава javaScript не такой уж и тормозной
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

97. "Взгляд на производительность JavaScript от одного из разрабо..."	–1 +/–
Сообщение от Kodir (ok) on 18-Июл-13, 22:38
ЖабоСкрипт не нужен уже просто за то, что это жабоскрипт. Как тот же ЛИСП или Хацкель - маргинальные уникумы для узкого круга некритичных задач. Плюс, сама природа "динамики" - её уже не разогнать ничем. Да и сама опасность узнавать об ошибке только в рантайме - бомба. Оно нам надо??
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

114. "Взгляд на производительность JavaScript от одного из разрабо..."	+/–
Сообщение от Аноним (??) on 22-Июл-13, 11:46
>> В своей заметке Шай проводит достаточно много аналогий с Java и, в частности, приводит пример достижения приемлемой производительности Java Mobile на телефонах Nokia с экраном 240x320 и 2 Мб ОЗУ. оно еще существует?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема