Сообщение Re[4]: [Nitra] Пример простого языка вычисляющего выражения от 10.12.2015 12:40
Изменено 10.12.2015 13:10 VladD2
Здравствуйте, _someuser, Вы писали:
_>В этом плане интересен вопрос, как будет отличаться производительность реализации парсера и типизации на найтре от решарпера или рослина. Скажем, насколько знаю, в рослине поддерживается инкрементальный парсинг, а в найтре пока нет (насколько понял планируется, но пока не в приоритете).
Основная наша цель на сегодня обеспечить приемлемую для использования в IDE производительность. Мы вибираем архитектуру позволяющую достичь необходимой производительности. На оптимизации времени не хватает. Не буду скрывать. Но все спроектировано так, чтобы оптимизации было не сложно добавить в дальнейшем (и при этом не пришлось бы сильно все менять).
В конечном итоге планируем сделать и инкрементальный парсинг, и инкрементальную типизацию. Те же зависимые свойства выбраны, в не малой степени, под с учетом того, что их можно пересчитывать инкрементально.
_>Интересно узнать, у вас, как разработчиков найтры, какие мысли по поводу производительности? Т.е. почему ваша реализация будет работать не медленнее или быстрее?
Мы не гарантируем, что она будет быстрее любой другой. Это физически невозможно, так как конкретную реализацию всегда можно заоптимизировать сильнее, чем общую. Мы делаем так, чтобы производительности хватало для комфортного использования. Скажем, если мы печатаем в редакторе, то не должно возникать тормозов. То же инкрементальное редактирование нужно именно для того, чтобы комфортно печатать было и в больших файлах.
_>В этом плане интересен вопрос, как будет отличаться производительность реализации парсера и типизации на найтре от решарпера или рослина. Скажем, насколько знаю, в рослине поддерживается инкрементальный парсинг, а в найтре пока нет (насколько понял планируется, но пока не в приоритете).
Основная наша цель на сегодня обеспечить приемлемую для использования в IDE производительность. Мы вибираем архитектуру позволяющую достичь необходимой производительности. На оптимизации времени не хватает. Не буду скрывать. Но все спроектировано так, чтобы оптимизации было не сложно добавить в дальнейшем (и при этом не пришлось бы сильно все менять).
В конечном итоге планируем сделать и инкрементальный парсинг, и инкрементальную типизацию. Те же зависимые свойства выбраны, в не малой степени, под с учетом того, что их можно пересчитывать инкрементально.
_>Интересно узнать, у вас, как разработчиков найтры, какие мысли по поводу производительности? Т.е. почему ваша реализация будет работать не медленнее или быстрее?
Мы не гарантируем, что она будет быстрее любой другой. Это физически невозможно, так как конкретную реализацию всегда можно заоптимизировать сильнее, чем общую. Мы делаем так, чтобы производительности хватало для комфортного использования. Скажем, если мы печатаем в редакторе, то не должно возникать тормозов. То же инкрементальное редактирование нужно именно для того, чтобы комфортно печатать было и в больших файлах.
Re[4]: [Nitra] Пример простого языка вычисляющего выражения
Здравствуйте, _someuser, Вы писали:
_>В этом плане интересен вопрос, как будет отличаться производительность реализации парсера и типизации на найтре от решарпера или рослина. Скажем, насколько знаю, в рослине поддерживается инкрементальный парсинг, а в найтре пока нет (насколько понял планируется, но пока не в приоритете).
Основная наша цель на сегодня обеспечить приемлемую для использования в IDE производительность. Мы вибираем архитектуру позволяющую достичь необходимой производительности. На оптимизации времени не хватает. Не буду скрывать. Но все спроектировано так, чтобы оптимизации было не сложно добавить в дальнейшем (и при этом не пришлось бы сильно все менять).
В конечном итоге планируем сделать и инкрементальный парсинг, и инкрементальную типизацию. Те же зависимые свойства выбраны, в не малой степени, с учетом того, что их можно пересчитывать инкрементально.
_>Интересно узнать, у вас, как разработчиков найтры, какие мысли по поводу производительности? Т.е. почему ваша реализация будет работать не медленнее или быстрее?
Мы не гарантируем, что она будет быстрее любой другой. Это физически невозможно, так как конкретную реализацию всегда можно заоптимизировать сильнее, чем общую. Мы делаем так, чтобы производительности хватало для комфортного использования. Скажем, если мы печатаем в редакторе, то не должно возникать тормозов. То же инкрементальное редактирование нужно именно для того, чтобы комфортно печатать было и в больших файлах.
_>В этом плане интересен вопрос, как будет отличаться производительность реализации парсера и типизации на найтре от решарпера или рослина. Скажем, насколько знаю, в рослине поддерживается инкрементальный парсинг, а в найтре пока нет (насколько понял планируется, но пока не в приоритете).
Основная наша цель на сегодня обеспечить приемлемую для использования в IDE производительность. Мы вибираем архитектуру позволяющую достичь необходимой производительности. На оптимизации времени не хватает. Не буду скрывать. Но все спроектировано так, чтобы оптимизации было не сложно добавить в дальнейшем (и при этом не пришлось бы сильно все менять).
В конечном итоге планируем сделать и инкрементальный парсинг, и инкрементальную типизацию. Те же зависимые свойства выбраны, в не малой степени, с учетом того, что их можно пересчитывать инкрементально.
_>Интересно узнать, у вас, как разработчиков найтры, какие мысли по поводу производительности? Т.е. почему ваша реализация будет работать не медленнее или быстрее?
Мы не гарантируем, что она будет быстрее любой другой. Это физически невозможно, так как конкретную реализацию всегда можно заоптимизировать сильнее, чем общую. Мы делаем так, чтобы производительности хватало для комфортного использования. Скажем, если мы печатаем в редакторе, то не должно возникать тормозов. То же инкрементальное редактирование нужно именно для того, чтобы комфортно печатать было и в больших файлах.