- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
String.prototype.startsWith=function(b){
if(this.length<b.length){
return false
}
for(var a=0;a<b.length;++a){
if(this.charAt(a)!==b.charAt(a)){
return false
}
}
return true
};
String.prototype.endsWith=function(b){
if(this.length<b.length){
return false
}
var c=b.length-1;
for(var a=this.length-1;a>this.length-1-b.length;--a){
if(b.charAt(c--)!==this.charAt(a)){
return false
}
}
return true
};
String.prototype.contains=function(a){
return this.indexOf(a)!==-1
};
String.prototype.LastIndexOf=function(d,c){
if(this.length===0||d===null){
return -1
}
if(d.length>this.length){
return -1
}
if(isNaN(c)){
c=this.length-d.length
}
var a=false;
for(var b=c;b>=0;--b){
a=true;
for(var e=0;e<d.length;++e){
if(this.charAt(b+e)!==d.charAt(e)){
a=false;
break
}
}
if(a){
return b
}
}
return -1
};
String.prototype.LastIndexOf_char=function(a){
for(var b=this.length-1;b>=0;--b){
if(this.charAt(b)===a){
return b
}
}
return -1
};
String.prototype.setCharAt=function(b,a){
if(b>this.length-1){
return str
}
return this.substr(0,b)+a+this.substr(b+1)
};
String.prototype.countCharAppearances=function(a){
var b=0;
for(var c=0;c<this.length;++c){
if(this.charAt(c)==a){
++b
}
}
return b
};
Сорри, что много буков, но тут каждую функцию можно воспринимать как отдельное произведение.
Разбираю бред какого-то безымянного идиота :(
Follow us!
Ну и дальше все в таком же ключе.
Это что еще за неоптимальное говно? Делать поиск во всей строке чтобы узнать начинается ли она с b?
Но, на мой взгляд, от етой оптимизации толку не много т.как и строками большими Яваскрипту оперировать не прийдется, а код читать прийдется.
>т.как он (JavaScript) никогда быстрым не был, и не пытался
как раз и говорит, что нужно искать оптимальные пути. Раз язык не быстр, значит задача производительности на программисте.
Но самое главное то, что выигрыш копеечный по сравнению с тем, что нужно разбирать код, который делает какую-то фигню.
1. Компилятор :) (его нет в ЯваСкрипте, как данности - никто не знает, как он выглядит)
2. Языковые конструкции для обращения к компилятору (volatile, inline, define и т.д.) которые на уровне языка позволяют объяснить компилятору что нужно делать с кодом.
3. Инструметны для отладки скомпилированого кода. (Дебажить MIR И пытаться понять каким образом оно относится к исходникам? Нет таких инструментов, и не скоро появятся).
Ничего такого даже близко нет и не предвидится, да и не особо нужно. А так, конечно, можно скомпилировать, только обидно потом будет за бесцельно потраченное время.
1) V8 increases performance by compiling JavaScript to native machine code (x86, ARM, or MIPS CPUs), before executing it, versus executing bytecode or interpreting it. *
2) Всю жизнь думал, что компиляция - процесс преобразования ЯВУ в машинный язык. Есть уйма компиляторов, которые порождают объектные файлы, но, при всём этом, управлять процессом компиляции не получится.
3) Вероятнее всего, отлаживаться/профилироваться будет "исходник". Пока не знаю, как это должно выглядеть.
* я знаю, что пользоваться цитатами из викижопии некрасиво
я знаю, что пользоваться цитатами
Это скорее всего гонево.
Это на столько бессмысленно, что даже тот же V8 практически ничего с ним не делает - так и оставляет код в виде строк. Он их приводит к какой-то нормальной форме, и так ими и оперирует. Оптимизации может делать JIT гогда компилирует в MIR. На это, вобщем-то вся и надежда.
Т.е. представьте себе, что вы пишете на С++, но с условием, что никаких типов кроме хешей и строк использовать нельзя, и представьте, что из этого сделает компилятор, как бы вы ни старались.
За счет этого языки типа Си и оптимизируются хорошо - т.как все эти проверки можно не делать. Но если начинать поголовно их проверять, так и Си будет не на много быстрее Яваскрипта.
А вот про целые индексы в той же Lua прикольная оптимизация - там объект состоит из двух половинок - целочисленного вектора и хэш таблички. Целочисленные индексы, идущие более-менее по порядку, попадают в вектор, а остальной хлам в хэш.
man escape analysis
Ну хотя погорячился. Локальные переменные то можно оптимизнуть.
И никто никогда не узнает какого типа была "а".
Я, конечно, сам виноват, что задал дискуссии неправильный вектор. Может и не компилируют, но факт остаётся. Есть к языку некий интерес и он сохраняется. Ведутся работы над ускорением тех же браузерных движков, да так, что я уже не знаю, кто там сейчас быстрее - V8, JaegerMonkey или оперское. Есть даже браузерные игры. Теоретически, существует ниша для высокопроизводительной реализации.
P.S. я сам не являюсь особым фанатом JS
https://developers.google.com/v8/design
P.S. Статейка достаточно короткая.
Но я могу понять почему их пытаютя улучшать. Изза того, что браузеры не могут договориться о том, чтобы стандартизировать виртуальную машину (и, особенно, Мозила в лице Б. Эйка) под всякими предлогами желающие использовать Яваскрипт. А работать как-то надо же...
Главный контраргумент Мозилы заключается в том, что Яваскрипт по факту доступен для просмотра и правки, и это якобы помогает избежать ситуаций с закрытыми исходниками или кодом, который потенциально вредит пользователю.
На что есть куча контраргументов. Например, байткод кораздо проще анализировать (не человеку) на предмет вредоносности. Когда Яваскрипт упаковывают, он практически становится нечитабельным, и, вобщем, проще было бы поступать как и с любым другим софтом: нужны исходники - нате адресс, нате лицензию.
Но даже если остановиться на варианте с интепретируемым языком, то все равно было бы хорошо если бы этот язык позволял как-то помогать себя оптимизировать. Собственно, такие мысли были при работе над ЕС4, но почему-то ее не приняли, вместо этого есть промежуточное говно ЕС5, и вообще, апогей маразма - ЕС6. В котором вместо возможных оптимизаций понадобавляли кучу дублирующих возможностей, всякий "сахар" и т.д. ничего по-содержанию не поменяв.
Так что прогноз на близжайшие лет 5 совсем неутешительный :)
Для JS куча библиотек и инструментов, для него есть стандарт, его знает миллионы людей.
Переход на другой язык потребует огромное количество труда и ресурсов. В частности, поэтому Dart и буксует.
К тому же, с появлением Clojure->JS и CoffeeScript, многие предпочитают писать на приличном языке и компилить в богомерзкий JS, который работает во всех браузерах, чем учить какой-то новый язык, который поддерживает один/два браузера и для которого нет библиотек.
На самом деле, большая часть библиотек направлена на борьбу с самим Яваскриптом или разногласиями между браузермаи в его интерпетации. Опять же, язык высокого уровня тяжело одинаково интерпретировать. Байткод гораздо проще.
Дарт, как бы и не торт... ну чуть лучше, да, но он не сильно воодушевляющий. Хз, может если бы Гугл его активнее продвигали, то пользовались бы... но у них у самих есть много альтернатив, которые они же и продивгают, типа той же GWT. Так что им и не с руки.
Опять же, какой-то практический смысл в этом должен быть, мельком сужу по отрасли.
А так - еть куча хороших языков, куда лучше Яваскрипта, пригодных для того, чтобы использовать на сервере. Даже тот же ЕС4 (Флеш) можно использовать, и он не в пример быстрее Яваскрипта, но вот так вот.
В основном пространстве прямо.
Я думаю, если бы был интерес - оболочки написать не так проблематично.
Что мне самому не нравится - прототипированное программирование. Как-то это еретично слегка. Потому, наверное, и пишут одно говно сплошняком.
Т.е. Ява может и не на много лучше, теоретически, но ее преподают в вузах, книжки пишут и все такое. И поэтому когда попадаются проекты на Яве они, как правило, плохие только на 50-60%, в то время как проекты на Яваскрипте, как правило 100% мусор.
>>Яве они, как правило, плохие только на 50-60%
Смелое заявление.
>> большая часть библиотек направлена на борьбу с самим Яваскриптом
Вот на самом деле это сказано - в точности про жабу. Либы для борьбы с языком, с checked exceptions, c говнодизайном и убогостью языка.
Ну с чистым js бороться не надо. Там не с чем бороться.
Практически чуть ли не каждая библиотека пытается добавить к языку строгую типизацию, т.е. всякие проверки типа isString(), isBoolean() и т.д. - это примерно так же, как в PHP все пишут по CMS. Ну и всяческие методы, как ограничить свободу в смысле типов функций, полей объекта и т.д.
Т.е. по-сути, есть 2 главные проблемы: непредсказуемое поведение встроенных операторов, которые конвертируют типы как угодно (особо замечательны в этом плане == и +)
Отсутсвие своей общепринятой объектной системы. Т.е. в некотороых языках объектная система встроена в язык, в некоторых существуют одна-две конкурирующие реализации, а в Яваскрипте ее вообще нет. Т.е. кроме встроенных пяти типов - ничего. Ну а те самые библиотеки, как правило, ее пытаются как-то дописать. Но инструментов для этого нет, да и делают это, как правило, основываясь на прототипах / object хешах, которые делают это очень затруднительным.
Для сравнения можно взять объектную систему eieio (eLisp) - очень упрощенная версия CLOS написаная на самом eLisp'е. Не смотря на то, что eieio классы, так же как и Яваскрипт прототипы не равны в правах "настоящим" типам, можно основываясь на них строить ОО программу (можно запретить создание новых свойств у объектов, можно специализировать методы на объектах и т.п.) В Яваскрипте существуют объекты, но ничего ОО-шного с ними сделать нельзя...
И не надо. Идеология ведь другая.
>Практически чуть ли не каждая библиотека пытается добавить к языку строгую типизацию, т.е. всякие проверки типа isString(), isBoolean() и т.д.
Та оно-то не особо нужно. Ну да, все претензии потому что динамика, но просто надо привыкнуть.
В любом языке есть свои грабли.
Но так никто абсолютно на Яваскрипте не пишет. А без типов язык - ну так какой же это язык? Я не за ОО в Яваскрипте, я это привел, как пример беспомощности языка. Т.е. есть другие языки, которые тоже от природы не ОО, но в них есть инструменты позволяющие с этим как-то справиться.
Есть много подходов к типам. Яваскрипту, по моему мнению, больше всего бы подошло что-то типа как у Эрланга, там тоже встроенных типов минимум, а остальные строятся комбинацией из встроенных. Но, опять же, силами Яваскрипта, как он сейчас, это не реализовать.
Операторы - это не просто "динамика". В Лиспе или Эрланге тоже динамически, но, при необходимости, от этого можно отказаться. Т.е. оператор == работает неправильно, никому он такой не нужен, да и + тоже - только ошибок куча изза него, а заменить на что-то - язык такого не позволяет.
Тут наверное уместнее - борьба с IE. Это проблемы не к языку, а к браузерам - есть же стандарт.
>Что мне самому не нравится - прототипированное программирование.
Согласен. Причем серъезная ересь.
Может оно и нужно, но только использовать нужно аккуратно - по чуть-чуть.
>Потому, наверное, и пишут одно говно сплошняком.
Да-да.
Да. Это пиздец. Испортят язык.
А фф уперто внедряет эти говнофичи.
Может потому у них и выходит такое монструозное говно годзиллы.
Именно. И вариант с substr в разы читабельнее варианта с indexOF
Интереса ради провел эксперимент. В Хроме этот тест показывает, что до 10.000 (десяти тысячь) знаков до искомой подстроки на таком же количестве итераций вы просто практически ничего не заметите. Но если вы собираетесь обрабатывать строки длиннее, то да, есть серьезное преимущество у второго метода.
>тысячь
В принципе та же вонь, что я поднимал на счёт знака копирайта, но мерзко же читать, ребята...
За тест спасибо.
countCharOccurrences?