delphi4arab منتديات دلفي للعرب

للفائدة زيادة في الايضاح

بافتراض ان المبرمج يعرف ما يفعل ويبرمج بطريقة صحيحة ومع هذا هناك بعض الاشياء التي يمكنها ان تسرع بدء تشغيل التطبيقات في .NET

ما هو Ngen.exe؟

هو أداة تستخدم لتحويل ملفات الـ DLL أو EXE المكتوبة بـ MSIL (Intermediate Language) إلى كود أصلي (Native Code) خاص بالمعالج، وتخزينه في Native Image Cache. هذا يقلل من وقت الإقلاع لأنه يتجنب عملية JIT في كل مرة

من استخدم برنامج dbForge Studio for MySQL يمكنه ان يرى انه يستخدم نفس الاسلوب

 

بالنظر الى مسار الملفات والمكتبات فهو قد قام بتوليد صور أصلية من المكتبات لتسريع اداء التشغيل

ملاحظة هذه الطريقة تسرع من بدء التشغيل فقط لا علاقة لها فيما بعد فبعد التشغيل .net ليس لديه مشكلة في السرعة وان كان هناك مشكلة فهي من المبرمج

ملاحظة اخرى ان  Ngen.exe مخصص لي .net FreamWork  وليس الى net Core

الـ Net Core يستخدم معه  Native AOT حيث ينتج تطبيق بملف وحيد ومترجم ترجمة أصلية للغة الالة لا فرق بينها وبين ملفات ينتجها دلفي
المشكلة الوحيدة هي انه قيد التطوير وحديث ولهذا اذا كنت تستخدم مكتبات خارجية فلابد وان تكون مدعومة لمثل هذه العملية
وربما تحصل على تطبيق بعضه مترجم للغة الالة الاصلية وبعضه كما هو

ما هو Native AOT؟
هو أسلوب نشر يقوم بتحويل تطبيقك إلى ملف تنفيذي أصلي بالكامل (native binary)، بدون الحاجة إلى JIT أثناء التشغيل. هذا يؤدي إلى:

تقليل وقت الإقلاع بشكل كبير

تقليل حجم التطبيق

تقليل استهلاك الذاكرة

تحسين الأداء في بيئات محدودة الموارد مثل الحاويات أو الأجهزة الطرفية

اما ان كان الغرض هو تسريع التطبيق والمحافظة على استخدام netCore

بدائل عملية لتسريع الإقلاع في .NET 9

1. Trimming (التقليص)
تقنية تقلل حجم التطبيق عبر إزالة الأكواد غير المستخدمة أثناء النشر:
<PublishTrimmed>true</PublishTrimmed>

[*]تقلل حجم الـ DLLs
[*]تُسرّع التحميل الأولي

2. ReadyToRun (R2R) Compilation
تحويل أجزاء من التطبيق إلى كود أصلي مسبقًا، مشابه لـ Ngen ولكن مخصص لـ .NET Core و .NET 5+:

<PublishReadyToRun>true</PublishReadyToRun>

[*]يُسرّع الإقلاع
[*]لا يتطلب دعم Native AOT الكامل
[*]متوافق مع معظم المكتبات

3. تحسينات داخلية في .NET 9
بحسب مدونة Microsoft الرسمية، فإن .NET 9 يحتوي على أكثر من 350 تحسينًا في الأداء، منها:

• تحسينات في الـ JIT Compiler
  
• تقليل زمن الإقلاع عبر تحسينات في الـ GC
  
• دعم أفضل للـ async/await وعمليات I/O
  

مثال عملي في ملف المشروع:



طالما دخلت مايكروسوفت ( المصادر المفتوحة ) ووضعت يدها في (  Native AOT ) فلن تخلعهما حتى تنتهي منه
اذا اكتمل 100% فوقتها ستكون الضربة القاضية لدلفي 


فان كان يربش الان فلن يتحرك بعدها ابدا

فتخيل انك تعمل على دلفي وبدل من مكتبة VCL القديمة لديك مكتبة .NET انه شئ خيالي بالنسبة للمبرمج وهو ما خاطبتهم في كل مناسبة ان يكون لديهم شئ مثله
ركز على تطوير مكتبة VCL لتكون بقوة .NET وحديثة مثلها 
ولكنهم مشغولون بي IF 10 THEN SMALL , BIG


إذا اكتملت Native AOT في .NET وأصبحت تدعم كل المكتبات والأدوات، فستكون:

• نقلة نوعية في الأداء: تطبيقات تبدأ بسرعة البرق، بدون JIT، وبدون runtime overhead.
  
• سهولة في التوزيع: ملف تنفيذي واحد، بدون اعتماديات خارجية.
  
• أمان أعلى: لا يمكن عكس الكود بسهولة كما في IL.
  

(21-08-2025, 03:37 PM)الفجر الابيض كتب : [ -> ]

إقتباس :ايضاً بخصوص تطوير برامج سطح المكتب مع دوت نت، هل جربت انت تنشيء مشروع به اكثر من 20 فورم وكل فروم يحتوي على عدد كبير من ال controls؟ سوف يصبح المشروع ميت حيث لو كانت جاهزك مواصفاته ممتازة، وسرعة الرسم على الشاشة لا تقارن بدلفي بتاتاً في runtime.

اخشى ما اخشاه ان تكون العشرين سنة التي تعلمتها مجرد فهم لما يطرح بالمنتديات فلا علاقة لما ذكرت  ففيه الكثير من التهويل وقليل من الدقة الهندسية
ليس بالضرورة عدد النماذج (Forms) لا يؤثر على الأداء طالما أنها ليست كلها محملة في الذاكرة في نفس الوقت
عدد العناصر (Controls) داخل النموذج قد يؤثر على زمن التحميل الأولي للنموذج لكنه لا يجعل المشروع ميتاً كما تقول وحتى دلفي نشاهد بطئ نسبي بين نموذج خفيف ونموذج ممتلئ .

.NET (سواء WinForms أو WPF أو MAUI) يستخدم تقنيات ذكية في إدارة الذاكرة والرسم مثل lazy rendering وdouble buffering 

مقارنة واقعية مع Delphi :
الدلفي
سرعة التحميل الأولي
أسرع في بعض الحالات بسبب الرسم المباشر
الدوت نت
أبطأ نسبيًا بسبب abstraction

إدارة الذاكرة
الدلفي
أقل ذكاءً في إدارة الموارد
الدوت نت
Garbage Collection ذكي

دعم الأجهزة الحديثة
الدلفي
محدود في FireMonkey

الدوت نت
واسع في MAUI وWPF

التوسع المستقبلي
الدلفي
صعب بدون إعادة بناء

الدوت نت
سهل عبر MVVM وDI

Delphi قد يكون أسرع في رسم واجهة بسيطة، لكن .NET يتفوق في الاستقرار، التوسع، والتكامل مع النظام البيئي الحديث.

القول بأن المشروع "يموت" بسبب كثرة النماذج أو العناصر غير دقيق هندسيًا. ما يقتل المشروع هو سوء التصميم، لا عدد النوافذ. في .NET، يمكن تحميل النماذج عند الطلب، استخدام UserControls لتقسيم الواجهة، وتطبيق أنماط مثل MVVM لتقليل الحمل على الذاكرة.

أما من ناحية الأداء، فـ .NET يقدم أدوات مثل SuspendLayout, DoubleBuffered, وVirtualization في WPF، وكلها مصممة لتحسين الأداء حتى في الواجهات الثقيلة.

Delphi قد يرسم أسرع، لكنه لا يدير الموارد بذكاء، ولا يتكامل مع REST APIs أو Azure أو الذكاء الاصطناعي كما تفعل .NET.

التقنية ليست سباقًا في "من يرسم أسرع"، بل في "من يبني نظامًا قابلًا للتوسع، الصيانة، والتكامل مع المستقبل".

ADO.NET ليست تقنية مهجورة، بل هي الأساس المنخفض المستوى الذي تبني عليه معظم مكتبات الوصول إلى البيانات في .NET، بما فيها Entity Framework وDapper.

مايكروسوفت لا "تحذر" من استخدامها، بل توصي بها في الحالات التي تتطلب أداءً عاليا وتحكما مباشرا، مثل التطبيقات المالية أو أنظمة الـ OLTP الثقيلة.

من الخطأ اعتبار ADO.NET "تقنية قديمة" فقط لأنها لا تحتوي على ORM. هي أداة منخفضة المستوى، وليست بدائية.

EF (خصوصًا Core) يقدم أداء جيدًا إذا استُخدم بشكل صحيح:

عبر AsNoTracking

واستخدام Compiled Queries

وتجنب Lazy Loading في السيناريوهات الحساسة.

نعم، هناك طبقات إضافية، لكنها تمنحك قابلية صيانة، واختبار، وتجريد لا تحصل عليها مع ADO.NET أو UniDAC.

من يشتكي من أداء EF غالبًا يستخدمه بطريقة غير مثالية، أو يقارن بين سيناريوهات غير متكافئة.

القول بأن ADO.NET قديمة وغير منصوح بها فيه تبسيط مخل. هي أداة قوية لمن يريد التحكم الكامل في الاتصال والاستعلامات، وتُستخدم في الأنظمة الحرجة حتى اليوم. أما Entity Framework، فهو خيار ممتاز لمن يبحث عن إنتاجية وسهولة في التطوير، بشرط أن يفهم حدوده ويستخدمه بذكاء.
أما الأداء، فهو ليس ضحية الطبقات، بل ضحية سوء الاستخدام. من يعرف كيف يوازن بين التجريد والتحكم، سيبني نظاما سريعا وقابلا للصيانة، سواء استخدم EF أو ADO.NET أو حتى Dapper.

لاتقارن بين دلفي والفيجوال ستوديو فبيئة لا يوجد فيها حدث زر عجلة الفأرة لانها لازالت بنفس اسطر البرمجة المكتوبة قبل ظهور عجلة الفأرة من الظلم مقارنتها بنظام حديث وايضا الدوت نت في طريقة للسرعة فهي اسرع الان من اول ما عرفتها في 2003

للأسف النقاش معك لا طائل له، أنت تقرأ وتكبت ما تقرأه ولكن فعلياً ليس لديك خبرة عملية في كل ما تقوله.

كل ما ذكرته أعرفه بالتفصيل، لكن أنت تردد ما تقوله ميكروسوفت من ناحية تسويقية، لكن عمرك جربت أنت تقوم بعمل Benchmark حقيقي ومقارنة نظامين؟

كما ذكرت لا أريد الدخول في مناقشات عقيمة، انا تركت المنتديات العربية والنقاش من أجل النقاشات مع أشخاص مثلك، ومن جديد عدت هنا لمحاولة أفادة مجتمع دلفي لضعفه عربياً.

أذا انت مقتنع في دوت نت، توكل على الله كمل بها وأخرج من المنتدى.

انا لا ادخل في نقاشات عقيمة وانا دخلت فاترك اثر فيها ليستفيذ منه الاخرون
هناك فرق بين من يتحدث ويقدم مقالات ويذكر تفاصيل وبين من يقول كلام من عنده بدون اي ادلة او معطيات
ذكرتني بمناظرات الشيعة مع رامي عيسى ووليد اسماعيل
وحتى ترى ان كلامي علمي ومنطقي فنقطة واحدة فقط تبين ان ماتقوله خطاء
اسأل من تشاء من المبرمجين (هل كثرة النماذج تؤثر على الاداء ام لا ) فقط حتى ترى هل انت بحاجة الى مراجعة معلوماتك ام لا
وعلى فكرة اسأل مبرمج حقيقي لا تسأل بالمنتديات وهذه نقطة المفترض يفهمها مبتدئ برمجة ويدركها من اول تجارب له
النماذج طالما لم تحملها بالذاكرة فما المشكلة فيها ...!
وان كان هناك بطئ فهو مشكلة بالتصميم والكود بلا شك .
ولا تتشدد ولا تتعصب والا فلن تتعلم ولا يوجد احد يعرف اي شئ وكل شئ فكل يوم نتعلم ولازلنا نتعلم وسنبقى نتعلم سواء كنا نتعلم من عشرين سنة او خمس سنين
وانا اعمل على الدلفي وعلى الفيجوال ستوديو وعلى الماوي والاندرويد ستوديو والفايرمونكي والخ ولم ولن استقر بمكان واتسمر فيه اينما وجدت المرعى الاكثر خصوبة والاكثر امان فهو المكان المناسب لي وهو الوطن فليس لي وطن ثابت
وعلى العموم على الاقل الموضوع حرك المنتدى قليلا والقارئ بالنهاية هو الذي يحكم وليس انا او انت
على ذكر ( Benchmark  ) عندي نظامين لنفس قاعدة البيانات احدهما على دلفي والاخر على .net9 بدء التشغيل لهما الاثنان لا يذكر نفس الشئ حوالي 150 ملي ثانية وظهور النوافذ الفرعية بعد تحميل البيانات نفس الشئ تقريبا حوالي 5 ملي ثانية
ولهذا السؤال الحقيقي والمفيذ هو هل انت فعلت ذلك او بالاحرى هل تعاملت مع الدوت نت بالشكل الصحيح

هناك فرق بين .NetCore وبين .Net FrameWork ليس في الكود والثقنيات فقط وانما حتى في  NET SDK-style فالتنسيقات مختلفة عن بعضها
يعني لا تستطيع نسخ مكونات من مشروع من هذا ولصقها في المشروع هذا
كما انه في .netcore المنطق البرمجي كله يتم وضعه في ملف dll وملف exe مجرد مشغل host  يقوم بتحميل و تشغيل ملف dll عبر CLR
وهذا الخيار
<PublishSingleFile>true</PublishSingleFile>
يقوم بدمج كل ملفات DLL في ملف وحيد exe

ماذا حصل في الاصدارة الجديدة
الم يحن موعدها بعد فلا يوجد لدينا صبر لنجرب if small then 100 then 200
ونحدث منظوماتنا على هذا التحديث الجديد

نحن هنا لسنا لتحجير ادمغتنا على صخرة اما هي واما فلا او على الاقل انا ان لم يكن الاخرون مثلي

ولهذا سأضطر لعرض بدائل لمن لا يريد ان يبقى يطلق البخور لصخرة دلفي لعلها تأتي بالمطر

لماذا الان اهاجم دلفي بعد هذه السنوات ...؟
لان الطريق الذي كان يجب ان يسلكه شد عنه وعلى العموم وجدت مكونات مفتوحة المصدر تعمل بشكل جيد على الدوت نت ويمكن ترجمتها بسهولة الى Native Aot اي سريعة تماما مثل دلفي وقوية من الدوت نت بل اكثر قوة لانها لا تعتمد على الدوت نت فقط وانما على مكتبات اخرى معدة بالجافا وال C++ وغيرهم

انها  Avalonia-Controls معدة للعمل على ويندوز وماك ولينوكس واندرويد وايفون ولكل شئ




مكونات ومكتبات حديثة ومتطورة باستمرار تغنيك عن كل شئ وليست مثل مكونات دلفي القديمة والتي تنتظر سنوات لتجد انهم اضافو لها خاصية title

تمتعوا بهذا الجمال



هل هذا مألوف لكم



وهل هذا مألوف لكم




أشعر ان ما تمنيناه في دلفي يتحقق بمكان أخر والمطر الذي انتظرناه طويلا يهطل بارض اخرى

لا احد يطلب منكم ان تتركوا دلفي ولكن الرهان على الحصان الخاسر مرة ومرتين وثلاث بلا فائدة هو المشكلة

---

جربت بهذه الادوات قبل قليل نموذج فيه 35 اداة
و تجربة سرعة التشغيل


والنتيجو كانت 26 جزء من الثانية ، اي ظهور النموذج بادواته كاملا وهي نتيجة قد ان لم تكن حتى اسرع من الدلفي فهي مثله
للعلم لم احول التطبيق الى Native AOT وانما بعض الاجراءات المذكورة في النقاش فقط

للعلم من مهتم بالدلفي صدرت قبل قليل النسخة الجديدة

للمقارنة بينها واصدارات دلفي الاخرى
https://www.embarcadero.com/docs/rad-stu...matrix.pdf

من عنده ساعة ونصف يمكنه مشاهدة هذا..