Комментарии 67
А что за единица измерения производительности К? (200К)
Ну и зачем?
Как-то все так сумбурно.
Было бы интересно ещё увидеть колонку SQL Server CE
Хехе, месье знает толк в извращениях :)
Скорее наоборот — для .NET это обкатанное надёжное решение, которое ещё и обновляется отдельно. Ну и принципиально CE ближе к взрослому серверу, чем SQL Lite.
Код SQLite один из самых вылизанных. Смысла в портировании не вижу вообще. То есть один смысл есть — работа в условиях, где нельзя использовать неуправлемый код, например ASP.Net хостинг. с другой сторны, на хостинге будет MS SQL Server. Так что практического смысла в портированиинет. Впрочем, сам авторор пишет
Q: Since SQLite has a windows dll and an executable you can download why port to C#?
A: It was an exercise to learn the C# language
Q: Since SQLite has a windows dll and an executable you can download why port to C#?
A: It was an exercise to learn the C# language
этот порт нужен в первую очередь для внедрения в silverlight-приложения для организации внутренней базы данных с доступом чрез sql-запросы. это очень важно и нужно для silverlight-разработчиков.
А разве на ASP.NET нельзя использовать неуправляемый код? о_О
Или это уже на шаред-хостингах его запрещают?
Или это уже на шаред-хостингах его запрещают?
смысл в том чтобы не парится по поводу архитектуры под которой будет запущено это дело.
а думать, что же положить в дистрибутив, x86 или x64 версию — не каждому хочется.
а думать, что же положить в дистрибутив, x86 или x64 версию — не каждому хочется.
а в каких там случая pinvoke юзается?
А практически во всех.
А как отказ от PInvoke убыстрит код?
Думаете, что родное C# API быстрее, чем вызов WinAPI через PInvoke?
Мне кажется, что должно быть плюс-минус полпроцента.
Или я чего-то не понимаю?
Думаете, что родное C# API быстрее, чем вызов WinAPI через PInvoke?
Мне кажется, что должно быть плюс-минус полпроцента.
Или я чего-то не понимаю?
Сам механизм P/Invoke не очень шустрый, ибо состоит из преобразования managed переменных в unmanaged параметры, обратной операции и всякой побочной возни.
Это особенности работы p/invoke.
Тормоза при переключении между managed и unmanaged кодом (маршализация и пр.) может сожрать всё преимущество в скорости C кода.
Тормоза при переключении между managed и unmanaged кодом (маршализация и пр.) может сожрать всё преимущество в скорости C кода.
Я вот к чему. Маршализация нужна, хоть она находится в P/Invoke, хоть в родных библиотеках.
Или именно сам P/Invoke тормозной?
Или именно сам P/Invoke тормозной?
Вообще основные тормоза будут при маршализации, я считаю. Функции без параметров будут быстрее запускаться, чем функции с параметром.
Ага, привожу пример:
Ага, привожу пример
[DllImport( «kernel32», SetLastError = true )]
static extern int LockFile(int hFile, int dwFileOffsetLow, int
dwFileOffsetHigh, int nNumberOfBytesToLockLow, int nNumberOfBytesToLockHigh);
Вот чего-то мне кажется что маршализация ничего не стоит.
[DllImport( «kernel32», SetLastError = true )]
static extern int LockFile(int hFile, int dwFileOffsetLow, int
dwFileOffsetHigh, int nNumberOfBytesToLockLow, int nNumberOfBytesToLockHigh);
Вот чего-то мне кажется что маршализация ничего не стоит.
Это пример чего, извини:)
Вот тебе для размышлений другой:
stackoverflow.com/questions/459107/net-marshalling-speed
Вот тебе для размышлений другой:
stackoverflow.com/questions/459107/net-marshalling-speed
Пример конкретной штуки которая конкретно в этом приложении C#-Sqlite сделана на P/Invoke. Мне кажется, что маршализация тут не стоит ничего.
С ссылочки цитирую из комментариев «Unfortunately, that extreme precision means a cost of roughly 2.5 seconds per run. Removing the timing code removed that time constraint.»
С ссылочки цитирую из комментариев «Unfortunately, that extreme precision means a cost of roughly 2.5 seconds per run. Removing the timing code removed that time constraint.»
очень ждем
автор, кстати, говорил, что производительностью вообще не занимался, его интересовал только сам построчный порт с языка Си.
кстати, стоит тут дополнить про название, так как SQLite — это торговая марка, то с названием были по началу проблемы, но потом автор SQLite согласился на название C#-SQLite
автор, кстати, говорил, что производительностью вообще не занимался, его интересовал только сам построчный порт с языка Си.
кстати, стоит тут дополнить про название, так как SQLite — это торговая марка, то с названием были по началу проблемы, но потом автор SQLite согласился на название C#-SQLite
А не проще ли было бы портировать HSQLDB или Apache Derby с Java?
Размер бинарника 528KB против 506KB оригинального. Неплохо.
22Кб это да, реальное достижение :D
НЛО прилетело и опубликовало эту надпись здесь
Вот уж я бы не сравнивал размеры бинарников, ибо к 528KB надо ещё прибавить 20 метров самого .NET, без которых он не запустится…
НЛО прилетело и опубликовало эту надпись здесь
Это всё понятно. Но, тем не менее, сравнивать файл .NEТ и нативный и говорить, — «ух, ты! какой маленький!» крайне не корректно. Иначе в пределе получаем некий абстрактный язык программирования в котором sqlite занимает один байт, при размере среды выполнения — сто мегабайт. Можно даже до одного бита ужать: 1 — есть sqlite, 0 — нет sqlite :)
Тогда и к оригинальному бинарнику стоит прибавить ещё десяток метров libc :)
Что будем прибавлять к Windows-версии sqlite.dll? Размер 243 Кб. Из зависимостей — только msvcrt.dll (335 КБ). Итого ~600 Кб.
Будем прибавлять kernel32.dll :)
Фреймворк он есть, он дан нам свыше и включать его в размер программы неправильно.
Фреймворк он есть, он дан нам свыше и включать его в размер программы неправильно.
угу, тогда я сейчас начну страшным голосом кричать какие мальенкие программы получаются на MSVC++ 150 К на программу с гуями! Ну, и ещё пять метров билиотек…
Библиотеки эти MSVC++ ставятся Windows Update для всех? Или их все-таки надо с собой таскать?
В том-то и приккол — что надо с собой таскать. Т.к. они могут быть в системе. Могут не быть. Могут быть, но другой версии. В результате установленнео приложение занимает не много места, но вот инсталлятор должен содеражть все необходимые библотеки — иначе запросто может оказаться (и часто оказывается), что у пользователя чего-то не хвататет в системе.
Сравнивать некорректно, это да. Но совершенно по другой причине, не из-за рамера платформы .NET (может для полного счастья еще и размер винды прибавим тогда?).
Некорректно сравнивать потому, что CLR-код, и x86/x64-код — это абсолютно разные величины. И сравнение 528KB и 506KB — это вовсе не показатель. И, кстати, зачастую x86-приложения, портированные на .NET, получаются меньше.
Некорректно сравнивать потому, что CLR-код, и x86/x64-код — это абсолютно разные величины. И сравнение 528KB и 506KB — это вовсе не показатель. И, кстати, зачастую x86-приложения, портированные на .NET, получаются меньше.
Есть провайдер System.Data.SQLite от http://sqlite.phxsoftware.com/
В чем принципиальные различия?
В чем принципиальные различия?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SQLite портирован на .NET