Вхід у систему JSON Вплив на продуктивність

Я бачу все більше статей про вхід у JSON. Ви також можете знайти його в блозі NodeJS. Чому всім так подобається? Я бачу лише участь інших операцій:

• Пару нових об’єктів створюється.
• Обряд об'єктів, що включає або обчислення довжини рядків, або множинні розподіли рядків.
• GCing всі лайно, що було створено.

Чи є якісь тести на працездатність під час використання журналу JSON та регулярного ведення рядків? Чи користуються люди JSON (для ведення лісозаготівлі) у проектах підприємств?

Журнал JSON дає можливість програмувати файл журналу програмно, навіть якщо формат змінився в часі .

Хороший приклад - журнали Apache. За замовчуванням Apache використовує commonформат для access.log:

"%h %l %u %t \"%r\" %>s %b"

Скажіть, що ви створили офлайн-аналізатор, який бере один із цих файлів журналу і обчислює з нього певну статистику.

В якийсь момент ви вводите субдомени у свою програму та включаєте virtual_hostдо своїх журналів (просто так ви зможете налагоджувати помилку, якщо з’являються проблеми з одним із субдоменів):

"%v %h %l %u %t \"%r\" %>s %b"

Ваш парсер не використовує virtual_hosts, але вам все одно потрібно адаптувати свій аналізатор до:

• прийняти новий формат журналу (зверніть увагу %vна голову формату журналу)
• як і раніше підтримує старий формат журналу (для старих файлів журналу)

Але якщо ви увійдете в JSON , ваш аналізатор навіть не помітить додане поле і може радісно проаналізувати нові журнали, а також старі журнали. І деякі інші аналізатори можуть використовувати додані поля, якщо вони існують .

І звичайно для вас , regexpsрозбирати JSON простіше, ніж писати для розбору журналів рядків.

Якщо ваша машина працює так близько до своїх меж, що такі проблеми дійсно мали б значення, у вас, швидше за все, є більш серйозні проблеми. Хоча можуть бути виняткові ситуації, коли це має певну різницю, багато програм (можливо, більшість) працюють на машинах, для яких різниця, якщо ви вводите JSON, простий текст або записи в базу даних, зовсім не має значення. Об'єкти, рядки та інші перетворення в більшості випадків доводиться робити в більшості випадків (якщо ви не входите в необроблений бінарний файл?).

Якщо для цього вам потрібні оцінки продуктивності, вам потрібно буде зробити їх самостійно на машині, на якій ви хочете запустити свій код, та із середовищем програмування, яке ви використовуєте щодня. Якщо є великі накладні витрати або взагалі якісь, залежить від багатьох речей. Якщо, наприклад, ви пишете веб-сайт в Ruby на Rails, ваші дані в більшості випадків є хешем, перетворення цього на JSON коштує вам майже нічого, оскільки внутрішнє представництво не так вже й далеко від того, що ви хочете написати (і це типово для коду Rails постійно обробляти такі об'єкти та структури даних).

Переваги знову залежать від ваших інструментів. Якщо у ваших бібліотеках вбудований JSON, ви можете легко прочитати його та відобразити це в якійсь формі. Ще раз як приклад: якщо припустити, що у вас був адміністраторський інтерфейс для вашого веб-сайту і ви хочете показати деяку інформацію журналу, що зберігається в JSON, ви можете це прочитати і відобразити як HTML в Ruby в одному рядку коду в деяких випадках.