Расширение класса ByteBuffer
Из документации : getSheetByName () «Возвращает ноль, если нет листа с заданным именем.» Так что вам нужно с этим справиться, смотрите вставленный блок if:
function deleteRows() {
var ss = SpreadsheetApp.getActiveSpreadsheet();
var s = ss.getSheetByName('delete containing');
if (s === null) {
ui = SpreadsheetApp.getUi();
ui.alert("No worksheet of that name"); // Note: displays in the worksheet GUI, not the scripts editor.
return false;
}
var r = s.getRange('A:A');
var v = r.getValues();
for(var i=v.length-1;i>=0;i--)
if(v[0,i]=='Substitution: ') // [sic] jshint kicking up a storm about this line!
s.deleteRow(i+1);
}
2 ответа
ByteBuffer абстрактен так, да, можно расширить его..., но я думаю, что Вы хотите сделать, расширяют класс, который на самом деле инстанцируют, который Вы, вероятно, не можете. Могло также случиться так, что конкретный, который заставляет инстанцированные переопределения что метод быть более эффективными, чем тот в ByteBuffer.
я также сказал бы, что Вы, вероятно, неправы в целом относительно всего того необходимого - возможно, это не, на какой Вы тестируете, но вероятно код там по причине (возможно, на других платформах).
, Если Вы действительно полагаете, что Вы корректны на нем, открывают ошибка и видят то, что они должны сказать.
, Если Вы хотите добавить к nio пакету, что Вы могли бы попытаться установить путь к классу начальной загрузки при вызове Java. Это должно позволить Вам вставить свои классы перед rt.jar. Введите Java-X, чтобы видеть, как сделать это, Вы хотите переключатель-Xbootclasspath/p.
Можно игнорировать уровни защиты при помощи отражения, но такие поражения цель производительности в значительной степени.
Вы НЕ можете создать класс в java.nio пакете - выполнение так (и распределение результата всегда) нарушает лицензию Java Sun и могло теоретически получить Вас в неприятности с законом.
я не думаю, что существует способ сделать то, что Вы хотите обойтись без идущего собственного компонента - но я также подозреваю, что Вы уступаете искушению преждевременной оптимизации. Предположение, что тесты корректны (который микросравнительные тесты часто не): Вы действительно уверены, что доступ к ByteBuffer будет узким местом производительности в Вашем реальном приложении? Это довольно не важно, мог ли ByteBuffer.get () быть в 4 раза быстрее, когда Ваше приложение только тратит 5% своего времени там и 95%, обрабатывающих данные, это выбирается.
Желание обойти все проверки ради (возможно чисто теоретический) производительность не звучит как хорошая идея. Кардинальное правило настройки производительности является "Первым, заставляют его работать правильно, ЗАТЕМ заставить его работать быстрее".
Редактирование: , Если, как указано в комментариях, приложение на самом деле тратит 20-40% своего времени в методах ByteBuffer и тестах, корректны, который означает потенциал ускорения 15-30% - значительный, но IMO, который не стоит начать использовать JNI или смешивать с источником API. Я попытался бы исчерпать все другие опции сначала:
- Вы использующий - сервер VM?
- приложение могло быть изменено для совершения меньшего количества вызовов к ByteBuffer вместо того, чтобы пытаться ускорить тех, которых это действительно делает?
- Использование профилировщик для наблюдения, куда вызовы прибывают из - возможно, некоторые прямые ненужный
- , Возможно, алгоритм может быть изменен, или можно использовать своего рода кэширование