هل GWT تسلسل java.lang.longs بكفاءة؟

Question

أقوم بإرسال معرفات الكائن ذهابًا وإيابًا من العميل إلى الخادم من خلال آلية GWT RPC. تخرج المعرفات من مخزن البيانات كطدوش (8 بايت). أعتقد أن جميع هوية بلدي لن تحتاج فقط إلى 4 بايت ، ولكن شيء عشوائي يستطع يحدث هذا يعطيني قيمة 5 بايت (أو أي شيء آخر).

هل ستكون GWT ذكية بشأن تعبئة هذه القيم في بعض الترميز المتغير الذي سيوفر المساحة في المتوسط؟ هل يمكنني تحديد أنها تفعل ذلك في مكان ما؟ أو هل يجب أن أكتب الكود الخاص بي لنسخ الوقت إلى ints وتراقب تلك المواقف الاستثنائية؟

شكرا ~

Answer 1

كما ذكر في توثيق GWT.

طويل: JavaScript ليس لديه نوع متكامل 64 بت ، يحتاج إلى اعتبار خاص طويلًا. قبل GWT 1.5 ، تم تعيين النوع الطويل ببساطة إلى النطاق المتكامل لقيمة نقطة عائمة JavaScript 64 بت ، مما يمنح المتغيرات الطويلة نطاقًا فعليًا أقل من 64 بت كاملة. اعتبارًا من GWT 1.5 ، يتم محاكاة البدائية الطويلة كزوج من الأعداد الصحيحة 32 بت ، ويعمل بشكل موثوق على نطاق 64 بت بأكمله. يتم محاكاة الفائض لمطابقة السلوك المتوقع. هناك اثنين من التحذيرات. سيكون للاستخدام الكثيف للعمليات الطويلة تأثير أداء بسبب المحاكاة الأساسية. بالإضافة إلى ذلك ، لا يمكن استخدام البدائل الطويلة في رمز JSNI لأنها ليست نوعًا من JavaScript الرقمي الأصلي.

إذا كان من الممكن أن تتناسب معرفاتك في عدد صحيح ، فقد تكون أفضل حالًا. خلاف ذلك ، إذا كنت تستخدم DTO ، اجعل IDS مزدوجًا ، وهو موجود بالفعل في JavaScript.

Answer 2

يستخدم GWT ضغط GZIP للاستجابات مع حمولة 256 بايت أو أكبر. يجب أن يعمل ذلك بشكل جيد إذا كان لديك الكثير من البايتات في ردك.

من عند RemoteServiceServlet.shouldCompressResponse:

يحدد ما إذا كان يجب أو لا ينبغي مضغوط الاستجابة لطلب servlet معين. تسمى هذه الطريقة فقط في الحالات التي يقبل فيها الطالب ترميز GZIP.

يعود هذا التنفيذ حاليًا إذا كان طول البايت المقدر لسلسلة الاستجابة أطول من 256 بايت. يمكن للفئات الفرعية تجاوز هذا المنطق.

لذلك ، يتحقق الخادم أولاً إذا كان المطلب (المتصفح ، عادةً) يقبل تشفير GZIP. داخليا، java.util.zip.GZIPOutputStream يستخدم - انظر RPCServerUtils. من جانب العميل ، إنها مهمة المتصفح إلغاء ضغط الحمولة النافعة Gzipped - نظرًا لأن هذا يتم في الكود الأصلي ، يجب أن يكون سريعًا إلى حد ما.