Текст после последней точки

[krutoy]

регулярки кушают

ага, отличный повод создавать стены лапши на каждую мизерную проверку. В оптимизации тоже меру надо знать

[devote]

создавать стены лапши

где ты увидел лапшу?

В оптимизации тоже меру надо знать

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

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

[krutoy]

devote,
К тому же, во первых, по поводу перфоманса еще можно поспорить. Во вторых, код с регулярками тоже может быть оптимизирован

var url = 'file:///d:/w.o.r.d.doc';


i=1000000
console.time('my stupid')
while(i--){
url.match(/\.([a-z]+)$/i)[1]
}
console.timeEnd('my stupid')

i=1000000
re=/\.([a-z]+)$/i
console.time('my better')
while(i--){
url.match(re)[1]
}
console.timeEnd('my better')



i=1000000
console.time('yours')
while(i--){
var ext = (ext = url.split('.')).length > 1 ? ext.pop() : '';
}
console.timeEnd('yours')
//в ноде:
//  my stupid: 423ms
//  my better: 401ms
//  yours: 425ms

В третих, во большинстве случаев можно обойтись тестом, а матчить только в поседнюю очередь. А так по любому будет быстрей.

где ты увидел лапшу?

она накапливается незаметно.

каждая мс на счету

Думаю, это говорит о фатальных недостатках архитектуры, в подавляющем большинстве случаев, если речь не идет о специализированном проекте, заточенном на максимальную производительнось.

[Safort]

devote,

Удивительно. Похоже исправили метод. А то ранее он работал иначе. Разбивал лишь по первому найденному вхождению... либо я что то путаю.

Путаешь, наверно, с этим http://habrahabr.ru/post/231071/#comment_7810751

[TimohaP]

вот никогда бы не додумался делать split'ом

[Safort]

TimohaP,
постоянно так делаю, чтобы регулярки не писать

[krutoy]

TimohaP,
Ага, выручает в примитивных случаях, типа вашего, или, например,

alert("1111/2222/3333/4444".split("/").reverse().join("/"))

Но шаг вправо -- наг влево,

alert("1111222233334444".replace(/(1+)(2+)(3+)(4+)/, "$4$3$2$1"))

и уже облом.
и даже вот это 1111/2222/3333/4444/ вы за*тесь реверсить сплитом
Так что особо не расчитывайте на него, в плане работы с текстом. Хотя в js split -- мощная, и юзабельная конструкция, она много че может, это да.

[bes]

devote,

var url = "file:///d:/w.o.r.d.doc";

console.time("time1");
var ext1 = url.split('.').pop();
console.log(ext1);
console.timeEnd("time1");

console.time("time2");
var ext2 = url.slice(url.lastIndexOf(".") + 1);
console.log(ext2);
console.timeEnd("time2");

chrome 39
doc
time1: 3.577ms
doc
time2: 0.144ms

var url = "file:///d:/w.o.r.d.doc";

console.time("time2");
var ext2 = url.slice(url.lastIndexOf(".") + 1);
console.log(ext2);
console.timeEnd("time2");

console.time("time1");
var ext1 = url.split('.').pop();
console.log(ext1);
console.timeEnd("time1");

chrome 39
doc
time1: 3.499ms
doc
time2: 0.124ms

в ff34 всегда разница в 0.01-0.02 ms

[devote]

К тому же, во первых, по поводу перфоманса еще можно поспорить.

ладно согласен, первый мой вариант не удачны, а вот этот обойдет регулярки:

var url = "file:///d:/w.o.r.d.doc";
alert((ext = url.lastIndexOf('.')) !== -1 ? url.substr(ext + 1) : '');

bes, уже предложил его выше)

var url = "file:///d:/w.o.r.d.doc";

i=1000000
re=/\.([a-z]+)$/i
console.time('my better')
while(i--){
var ext = url.match(re)[1]
}
console.log(ext);
console.timeEnd('my better')
 
 
 
i=1000000
console.time('yours')
while(i--){
var ext = (ext = url.lastIndexOf('.')) !== -1 ? url.substr(ext + 1) : ''
}
console.log(ext);
console.timeEnd('yours')

[krutoy]

этот обойдет регулярки:

Дело не в том, обойдет или нет, а в том, что не стоит экономить на копейках. Первоначально вообще надо писать не задумываясь о скорости, и лишь потом, если она недостаточна, приступать к оптимизации.

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