Про asm все ясно, на нем нужно уметь писать. Особенно для интеловских процессоров, Optimization Guide — 700 страниц убористого текста. А вот тест этот запустил на своей машине и результаты несколько отличаются от приведенных выше. Самым быстрым у меня оказался С/С++, по мне так очень ожидаемо. Больше всего удивил результат с JavaScript. Было бы интересно посмотреть на другие результаты
<button onclick="javascript: benchmark();">Run</button>
<div id="output"></div>
<script type="text/javascript">
function benchmark() {
const t0 = new Date();
let i_counter = 0;
let i_loop1 = 0;
let i_loop2 = 0;
let i_loop3 = 0;
for (i_loop1 = 0; i_loop1 < 10; i_loop1++) {
for (i_loop2 = 0; i_loop2 < 32000; i_loop2++) {
for (i_loop3 = 0; i_loop3 < 32000; i_loop3++) {
i_counter++;
if (i_counter > 50) {
i_counter = 0;
}
}
// If you want to test how the compiler optimizes that, remove the comment
//i_counter = 0;
}
}
const t1 = new Date();
// This is another trick to avoid compiler's optimization. To use the var somewhere
println("Counter: " + i_counter);
println("Elapsed time: " + (t1.valueOf() - t0.valueOf()) + " ms");
}
function println(s) {
const element = document.getElementById("output");
var para = document.createElement("div");
para.textContent = s;
element.appendChild(para);
}
</script>
Вероятно, для кого-то будет полезно. Сам столкнулся с этой проблемой несколько месяцев назад, пришлось переустанавливать WSL. Проблема собственно была в обмене файлами между WSL и Windows собственно проблема решилась достаточно просто созданием symbolic link к папке Windows.
Как-то так:
cd ~
ln -s /mnt/c/FilesForLinux
файлы в папке c:\FilesForLinuх после этого доступны для изменения и в WSL и в самой Windows
javascript несомненно прекрасен, но мне кажется перспективы у него не очень богатые, в связи с появлением WebAssembly, а это дело недалекого будущего. Конечно есть проблемы с унаследованным кодом, но веб очень подвижная среда. И наверное многие и неоднократно задавали вопрос, почему программирование для веб фактически возможно только на javascript при огромном количестве языков программирования, при этом вне веб-а первенство совсем не за javascript. Несомненно есть множество «языков» компилирующихся в javascript, но о большинстве из них мало кто слышал и наверное один из наиболее популярных это TypeScript (упомянут выше). Предварительная версия WebAssembly спецификации уже реализована во всех современных браузерах и это даст импульс разработке и созданию новых технологий разработке в веб. Я за многообразие.
Ну а это уже в качестве развлечения :o). Формирование HTML таблицы при помощи SQL-запроса.
select
5 as [BORDER],
(select TH from (
values
('Column #1'), ('Column #2'), ('Column #3')
) as T(TH) for xml raw(''), elements, type) as TR,
(select C1 as TD, C2 as TD, C3 as TD from (
values
('Item 1-1', 'Item 1-2', 'Item 1-3'),
('Item 2-1', 'Item 2-2', 'Item 2-3')
) as T(C1, C2, C3) for xml raw('TR'), elements, type)
for xml raw('TABLE')
Конечно не только для отправки писем. Service Broker очень удобная штука, чтобы выполнить какие-то действия асинхронно не снижая производительность пользовательской работы. В одном из проектов (стандартный клиент-сервер) использовал для отправки уведомлений пользователям системы об изменении состояния документов. Отправил сообщение и забыл, дальше работает Service Broker. Простой пример, пользователь отправляет документ на утверждение, при этом руководитель (подразделения, проекта и т.п.) в зависимости от настроек и типа документа должен получить уведомление (в системе, по почте или SMS) о том, что в системе появился документ, который необходимо утвердить. Вот логика формированием и отправкой уведомлений и была реализована с использование Service Broker. Иначе возникали тормоза при выполнении пользовательских действий.
Еще небольшое замечание, не очень хорошо что агент «дергает» процедуру достаточно часто раз в минуту, ведь ошибок может и не возникать весьма длительное время. Я бы воспользовался возможностями SQL Server Service Broker и в этом случае доставка сообщений будет действительно realtime и без участия SQL Server Agent.
Идея в следующем:
1. Создаем свой тип сообщения (CREATE MESSAGE TYPE)
2. Создаем контракт (CREATE CONTRACT)
3. Создаем процедуру для отправки сообщений
4. Создаем очередь (CREATE QUEUE), которая использует процедуру из п.3
5. Создаем службу (CREATE SERVICE), которая использует очередь из п.4 и контракт из п.3
Пример
-- активируем service broker
IF NOT EXISTS(SELECT * FROM master.sys.databases WHERE name = DB_NAME()
AND is_broker_enabled = 1)
BEGIN
DECLARE @sql nvarchar(max);
SET @sql = N'USE [master]; ALTER DATABASE [' + DB_NAME() + N'] SET NEW_BROKER; USE [' + DB_NAME() + '];';
EXECUTE(@sql)
SET @sql = N'USE [master]; ALTER DATABASE [' + DB_NAME() + N'] SET ENABLE_BROKER; USE [' + DB_NAME() + '];';
EXECUTE(@sql)
END;
GO
CREATE MESSAGE TYPE [http://tempuri.org/Notifications/SendErrorInfoEvent]
VALIDATION = WELL_FORMED_XML;
GO
CREATE CONTRACT [http://tempuri.org/Notifications/PostEventNotification]
(
[http://tempuri.org/Notifications/SendErrorInfoEvent] SENT BY ANY
);
GO
CREATE PROCEDURE [ProcessNotificationEvents]
AS
BEGIN
SET NOCOUNT ON;
DECLARE @message_body XML,
@message_type_name NVARCHAR(256),
@dialog UNIQUEIDENTIFIER ;
WHILE (1 = 1)
BEGIN
WAITFOR(
RECEIVE TOP(1)
@message_type_name = message_type_name,
@message_body = message_body,
@dialog = conversation_handle
FROM [EventNotificationQueue]
), TIMEOUT 2000;
IF @@ROWCOUNT = 0
BEGIN
BREAK;
END
IF (@message_type_name = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog')
BEGIN
END CONVERSATION @dialog ;
END
ELSE
BEGIN
/*
здесь реальный код обработки сообщения данные в @message_body
*/
RETURN 0
END
END
RETURN 0;
END
GO
CREATE QUEUE [EventNotificationQueue] WITH
STATUS = ON,
ACTIVATION (
STATUS = ON,
PROCEDURE_NAME = ProcessNotificationEvents,
MAX_QUEUE_READERS = 1,
EXECUTE AS OWNER
);
GO
CREATE SERVICE [http://tempuri.org/Notifications/EventNotificationService]
ON QUEUE [EventNotificationQueue]
(
[http://tempuri.org/Notifications/PostEventNotification]
);
GO
--
-- использование, можно оформить в виде процедуры
--
DECLARE @dialog UNIQUEIDENTIFIER;
BEGIN DIALOG CONVERSATION @dialog
FROM SERVICE [http://tempuri.org/Notifications/EventNotificationService]
TO SERVICE 'http://tempuri.org/Notifications/EventNotificationService'
ON CONTRACT [http://tempuri.org/Notifications/PostEventNotification]
WITH ENCRYPTION = OFF;
DECLARE @EventData XML;
-- формируем данные для отправки по электронной почте
SEND ON CONVERSATION @dialog
MESSAGE TYPE [http://tempuri.org/Notifications/SendErrorInfoEvent] (@EventData);
END CONVERSATION @dialog;
В коде могут быть неточности, но идея должны быть понятна.
для деревьев/списков: Microsoft.VisualStudio.PlatformUI.TreeViewColors. Посмотрите пространство имен: Microsoft.VisualStudio.PlatformUI там много полезного.
Не пробовали использовать элемент Microsoft.VisualStudio.Imaging.CrispImage и стандартные изображения Microsoft Visual Studio их кажется более 10-ти тысяч (Microsoft.VisualStudio.Imaging.KnownMonikers), Мне кажется там можно найти почти все.
Еще имеет смысл проверить auto close параметр БД, на всякий случай…
-- sqlcmd mode
:setvar DatabaseName "AdventureWorks2014"
IF DATABASEPROPERTY('$(DatabaseName)','IsAutoClose') = 1
begin
print 'autoclose = true'
ALTER DATABASE [$(DatabaseName)] SET AUTO_CLOSE OFF WITH NO_WAIT
print 'now autoclose = false'
end
При использовании Simple recovery model, полный бэкап автоматически освобождает используемое место в логе. Но само резервное копирование при Simple Recovery Model достаточно сильно нагружает подсистему ввода/вывода и чем дальше тем больше, базы данных обычно со временем растут, соответственно и копировать каждый раз приходится все большие объемы данных. Да и данных за 3-4 часа можно много потерять. Я сторонник использования Full Recovery Model, особенно если это БД для значимого/ключевого корпоративного приложения. Тогда можно себе позволить достаточно часто делать transaction log backup, а во времена минимальной нагрузки делать full database backup.
Главное периодически делать transaction log backup, это позволяет повторно использовать уже выделенное место в логе, иначе он будет расти бесконечно. Периодичность зависит от количества, размера транзакций и ценности данных.
Есть еще одна тема, приводящая к «случайным» зависаниям простых и в обычных условиях быстрых процедур — это расширение файлов БД. Например, по умолчанию БД создается в которой лог растет неограниченно прибавляя 10% к своему размеру. При размере лога в несколько Gb операция расширения лога может занять весьма существенное время. На производительность очень сильно влияет план резервного копирования БД, кроме этого часто к не очень хорошим последствиям приводит периодические операции shrink file/db
Я приведу относительные значения:
C/C++ MSVC/Windows - 1.00
C/C++ GCC/Ubuntu - 1.00
C# (.Net 4.61/Windows) - 1.22
C# (.Net Core/Ubuntu) - 1.50
Java 8 (Oracle/Windows) - 1.56
Java 8 (Oracle/Ubuntu) - 1.56
JavaScript (Edge 14.14393/Windows) - 1.27
JavaScript (Chrome 54/Windows) - 4.60
Как-то так:
файлы в папке c:\FilesForLinuх после этого доступны для изменения и в WSL и в самой Windows
Идея в следующем:
1. Создаем свой тип сообщения (CREATE MESSAGE TYPE)
2. Создаем контракт (CREATE CONTRACT)
3. Создаем процедуру для отправки сообщений
4. Создаем очередь (CREATE QUEUE), которая использует процедуру из п.3
5. Создаем службу (CREATE SERVICE), которая использует очередь из п.4 и контракт из п.3
В коде могут быть неточности, но идея должны быть понятна.
FORMAT (Transact-SQL)
ListViewStyle.xaml
Пример:
Необходимо использовать пространство имен
Например для ToolWindows
для деревьев/списков: Microsoft.VisualStudio.PlatformUI.TreeViewColors. Посмотрите пространство имен: Microsoft.VisualStudio.PlatformUI там много полезного.
Configure the user options