KLUBS

Сайт буду просматривать пользователи, и делать всякое разное. он должен быть максимально быстрым.

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

Api будет выполнять ресурсоёмкие задания: вычисления, запись из бд в файл и наоборот, и прочие функции которые не выдержит сайт.

API не делает задания. А вычисления и запись из бд в файл - не являются ресурскоемкими операциями в общем случае. Да и сайт их обычно тоже не производит. В таком контексте сайт - это, скорее, фронтенд. А вычисления будут производиться на сервере.

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

Тут вообще не понял. Многопоточность зависит от типа и настроек вебсервера (например, который стоит на nginx-ом). Чем не угодила асинхронность - тоже не понятно. И как она зависит с возможностью обрабатывать много и сразу - так же неясно. Очень упрощенно можно сказать, что с помощью асинхронности можно создать у пользователя впечатление, что сайт реагирует мгновенно (работает очень быстро)

Возможно, это все потому что 3 (4) часа ночи и вы переварили очень большой объем информации. Тогда попробуйте конкретизировать.

Если по существу:
1. Неважно, какой язык выбирать. Тот - который лучше всего знаешь. На любом языке можно реализовать что угодно. Большинство "производительности" достигается не за счет быстродействия стандартной библиотеки языка, а за счет кеширования, оптимизации sql запросов, настройки веб-сервера и базы данных и использования очередей.
2. Видимо, для вас важен вопрос: "Стоит ли разносить API сервера и клиент приложения на разные приложения, языки, инстансы?". Здесь ответить сразу не получится, потому что все зависит от задачи. Смотря как вы будете использовать свои инстансы. Какие вычисления будут проводиться и т.д. - больше конкретики по предметной области.

1. В большинстве проектов раньше использовал px. В последнее время перешёл на em и rem, где возможно. Для меня во многом удобнее чем px, правда не везде. Так же не стоит забывать о поддержке браузерами rem, если решите использовать
   
2. В 99% случаев выравниваю как Вы написали, padding и line-height. Самый удобный вариант. Со внешними шрифтами редко возникают проблемы. Не из-за того что у них отступы разные, а из-за того как выровнены символы относительно строки (в некоторых шрифтах символы могут быть смещены чуть выше или чуть ниже). Советую Вам использовать этот же метод. Просто на стадии дизайна, должен подбираться шрифт который "заточен" для веба.
   
3. Подключаю так же. Для конвертирования использую fontsquirrel. Можно поэкспериментировать с настройками, для получения оптимального отображения в браузерах
   
4. Родительскому контейнеру можно задать ширину 100% (чтобы растягивался по всей ширине окна) и overflow: hidden;
   
5. Safari поддерживает тень, но чуть темнее она там отображается, если не ошибаюсь. (-webkit-appearance: none; )
   
6. Скорее всего не сходятся цветовые профили. Почитайте тут
   
7. Так же использую разделение спрайтов по группам (в основном при использование различных типов, размеров иконок в них). В большинстве случаев это удобно (если используется много иконок)
   
8. С этим вопросом помочь не смогу, не изучал подробнее как большие фоновые изображения влияют на производительность и отображение
   

Влад Головач, "Искусство мыть слона" (http://uibook2.usethics.ru/)

Уши. Это называется ушами.

Спасибо огромное! Вот, ради чего все затевалось

Выглядеть может просто: на призму подают свет несколько источников, вся система крутится вокруг оси, совпадающей с лучом.
По спектрам не раскидать, потому что, может уже раскидали или подходящая полоса не такая уж широкая.
Почему нельзя разделить — ну потому что поляризации бывает N видов, а тут, грубо говоря, на спирали ты получаешь 360*N видов.
Амплитудная модуляция, думаю, в данном случае вообще не подходит из-за флуктуаций атмосферы: НЛО пролетают, облака всякие…

С точки зрения архитектурных концепций и феншуя должна быть некоторая прослойка уже просто потому, что контроллеру нужна view model а она отличается от того что есть просто model. пример нужно сделать pager… те у нас должна появиться view model с массивом этих объектов(реально все таки если база большая не совсем массив или список но да ладно) и номер страницы а это уже извиняюсь не то что в базе хранится…
тут уже контекст веб приложения есть некоторый о котором база и model данных не обязаны знать

А с точки зрения быстрой разработки можно и на прямую делать и нарушать все концепции mvc и прочее. Ну и если вы делаете простую админку на select update delete insert то там тоже мне кажется все болт клали на это

Пункт 0: используйте EF CodeFirst или POCO templates, тогда у вас будут «чистые классы» in the first place.
Пункт 1: все нижесказанное верно до тех пор, пока у вас контроллер работает напрямую с DAL, а не со слоем бизнес-логики или сервисов.

Есть таблица dbUsers в базе. В EF создаются классы dbUsers. Неким образом создается класс User. Слой данных работает с объектами EF а пользователю (контроллеру) отдает красивые чистые объекты класса User без лишней информации.

Это лишняя прослойка.

Есть таблица dbUsers в базе. В EF создаются классы dbUsers. Слой данных напрямую работает с этими объектам и передает их в контроллер. Т.е. контроллер работает с объектами типа dbUsers…

Это вполне нормально.

Во-первых, попробуйте Panda Recovery (как сказано в описании: Pandora Recovery actually recovers files permanently removed from Recycle Bin, files originally deleted using Shift + Delete keys bypassing Recycle Bin and files deleted from DOS prompt.)

Во-вторых, дабы в дальнейшем даже при нажатии Shift отправлять файлы в корзину, можно воспользоваться небольшим фокусом.

я с LabView работал только в рамках простейших схемотехнических решений, интересная штука, но очень легко довольно простую программу заставить течь. Частенько приходилось наблюдать картину, что после 5 минут работы сжиралась вся оперативка…

Статьи были бы к месту ибо их насколько я знаю не так много.

С удовольствием прочёл бы. Пишите.

«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.» (С) Стив Макконнелл.

«Говорить что Java хороша, потому как работает на всех платформах это тоже самое что говорить что анальный секс хорош, потому что работает на всех полах.»

It doesn't matter how many resources you have if you don't know how to use them, they will never be enough.

«Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.» Rick Cook.

Я бы сделал так — EAV для хранения информации, Sphinx для поиска.

Тогда эти ваши 300+ запросов будут делаться не к базе, а к сфинксу, а если это реализовать как мульти-запросы к сфинксу то работать будет очень быстро.

Ну и заранее делать можно не все запросы, а только основные, а по мере выбора подгружать аяксом

Stopwatch

Cobian Backup (http://www.cobiansoft.com/programz/cbSetup.9.5.1.212.exe)