যদি ব্যতিক্রম কখনও ছুঁড়ে না দেওয়া হয় তবে ট্রাই-ক্যাচ ব্লকগুলি ব্যবহার করা কি ব্যয়বহুল?


189

আমরা জানি যে ব্যতিক্রমগুলি ধরা খুব ব্যয়বহুল। তবে, কোনও ব্যতিক্রম কখনও নিক্ষেপ করা না হলেও জাভাতে ট্রাই-ক্যাচ ব্লক ব্যবহার করা কি ব্যয়বহুল?

আমি স্ট্যাক ওভারফ্লো প্রশ্ন / উত্তর পেয়েছি কেন চেষ্টা ব্লক ব্যয়বহুল? , তবে এটি নেট


30
সত্যিই এই প্রশ্নের কোন লাভ নেই। ট্রাই.সিএচের খুব নির্দিষ্ট উদ্দেশ্য রয়েছে। আপনার যদি এটি প্রয়োজন হয় তবে আপনার এটি দরকার। যাই হোক না কেন, ক্যাচ ছাড়া কোন পয়েন্টটি চেষ্টা করা উচিত?
জনএফএক্স

49
try { /* do stuff */ } finally { /* make sure to release resources */ }আইনী এবং দরকারী
A4L

4
সেই ব্যয়টি সুবিধার তুলনায় ওজন করতে হবে। এটি একা দাঁড়িয়ে না। যাইহোক, ব্যয়বহুল আপেক্ষিক, এবং যতক্ষণ না আপনি জানেন যে আপনি এটি করতে পারবেন না, ততক্ষণ কিছু না করার চেয়ে সর্বাধিক সুস্পষ্ট পদ্ধতিটি ব্যবহার করা বুদ্ধিমান হয় কারণ এটি আপনাকে এক ঘন্টার মধ্যে মিলিসেকেন্ড বা দুটি সাশ্রয় করতে পারে might প্রোগ্রাম কার্যকর।
জোয়েল

4
আমি আশা করি এটি "চলুন-পুনর্নবীকরণ-ত্রুটি-কোডগুলি" ধরণের পরিস্থিতির নেতৃত্ব নয় ...
মিকোয়াক

6
@ এসএফএক্স: জাভা with এর সাহায্যে আপনি এfinallytry-with-resources
অ ঘোড়া_বিহীন_নো নাম

উত্তর:


201

tryমোটামুটি কোনও ব্যয় নেই। tryরানটাইমের সময় সেটআপের কাজটি না করে কোডের মেটাডেটা সংকলনের সময় এমনভাবে কাঠামোযুক্ত করা হয় যে যখন কোনও ব্যতিক্রম ছুঁড়ে ফেলা হয়, এখন এটি স্ট্যাকটি হাঁটতে অপেক্ষাকৃত ব্যয়বহুল ক্রিয়াকলাপ করে এবং দেখে যে কোনও tryব্লক উপস্থিত রয়েছে যা এটি ধরবে would ব্যতিক্রম। সাধারণ লোকের দৃষ্টিকোণ থেকে মুক্তও tryহতে পারে। এটি আসলে আপনার ব্যয় ব্যতিক্রম ছুঁড়ে ফেলেছে - তবে আপনি শত বা হাজারো ব্যতিক্রম না ছড়িয়ে দিলে আপনি এখনও সেই মূল্যটি লক্ষ্য করবেন না।


tryএর সাথে কিছুটা ছোটখাটো খরচ জড়িত। জাভা কোনও tryব্লকের কোডে কিছু অপ্টিমাইজেশন করতে পারে না যা এটি অন্যথায় করবে। উদাহরণস্বরূপ, জাভা প্রায়শই একটি পদ্ধতিতে এটি দ্রুত চালিত করার জন্য নির্দেশাবলীর পুনরায় ব্যবস্থা করে দেয় - তবে জাভাতেও গ্যারান্টি দেওয়া দরকার যে যদি কোনও ব্যতিক্রম ছুঁড়ে দেওয়া হয় তবে পদ্ধতিটির সম্পাদনটি উত্স কোডে লিখিত হিসাবে তার বিবৃতি হিসাবে কার্যকর করা হবে বলে মনে করা হয় কিছু লাইন পর্যন্ত।

কারণ একটি tryব্লকে একটি ব্যতিক্রম ছোঁড়া যায় (চেষ্টা ব্লকের যে কোনও লাইনে! কিছু ব্যতিক্রম stopসংবিধানে নিক্ষেপ করা হয়, যেমন একটি থ্রেডে কল করে (যা অবমূল্যায়ন করা হয়), এবং এমনকি এটি ছাড়াও আউটঅফমিউরিঅরর প্রায় কোনও জায়গায় ঘটতে পারে) এবং এখনও এটি ধরা পড়ে এবং কোড একই পদ্ধতিতে পরবর্তী সময়ে চালিয়ে যেতে পারে, যে অপটিমাইজেশন তৈরি করা যেতে পারে সে সম্পর্কে যুক্তিযুক্ত হওয়া আরও বেশি কঠিন, তাই এগুলি হওয়ার সম্ভাবনা কম। (কারও কারও কাছে সেগুলি করার জন্য সংকলকটি প্রোগ্রাম করতে হবে, কারণ সম্পর্কে সঠিকতা এবং গ্যারান্টি ইত্যাদির জন্য ইত্যাদি। এটি 'ব্যতিক্রমী' বোঝার কোনও কিছুর জন্য একটি বড় ব্যথা হবে) তবে আবার, বাস্তবে আপনি এ জাতীয় জিনিসটি লক্ষ্য করবেন না।


2
কিছু ব্যতিক্রম অ্যাসিঙ্ক্রোনাসলি নিক্ষেপ করা হয় , সেগুলি অ্যাসিঙ্ক হয় না তবে নিরাপদ পয়েন্টগুলিতে নিক্ষেপ করা হয়। এবং এই অংশটির চেষ্টাটির সাথে কিছুটা ছোটখাটো খরচ জড়িত। জাভা কোনও চেষ্টা ব্লকে কোডে কিছু অপ্টিমাইজেশন করতে পারে না যা অন্যথায় এটির জন্য গুরুতর উল্লেখের প্রয়োজন। এক পর্যায়ে কোডটি চেষ্টা / ধরা ব্লকের মধ্যে থাকা খুব সম্ভবত। এটি সত্য হতে পারে যে চেষ্টা / ক্যাপ ব্লকটি ফলাফলের জন্য সঠিকভাবে জালিয়াতি তৈরি করা এবং তৈরি করা আরও শক্ত হবে তবে অংশটি ডাব্লু / পুনরায় সাজানো অস্পষ্ট।
বেটসেস

2
এছাড়াও একটি try...finallyব্লক catchকিছু অপ্টিমাইজেশন প্রতিরোধ করে?
dajood

5
@ পাতাসু "এটি আসলে আপনার ব্যয়ে ব্যয় করে এমন ব্যতিক্রম ছুঁড়ে ফেলছে " প্রযুক্তিগতভাবে, ব্যতিক্রম ছোঁড়া ব্যয়বহুল নয়; Exceptionঅবজেক্টটি ইনস্ট্যান্ট করা যা বেশিরভাগ সময় নেয়।
অস্টিন ডি

72

এর পরিমাপ করা যাক, আমরা কি?

public abstract class Benchmark {

    final String name;

    public Benchmark(String name) {
        this.name = name;
    }

    abstract int run(int iterations) throws Throwable;

    private BigDecimal time() {
        try {
            int nextI = 1;
            int i;
            long duration;
            do {
                i = nextI;
                long start = System.nanoTime();
                run(i);
                duration = System.nanoTime() - start;
                nextI = (i << 1) | 1;
            } while (duration < 100000000 && nextI > 0);
            return new BigDecimal((duration) * 1000 / i).movePointLeft(3);
        } catch (Throwable e) {
            throw new RuntimeException(e);
        }
    }

    @Override
    public String toString() {
        return name + "\t" + time() + " ns";
    }

    public static void main(String[] args) throws Exception {
        Benchmark[] benchmarks = {
            new Benchmark("try") {
                @Override int run(int iterations) throws Throwable {
                    int x = 0;
                    for (int i = 0; i < iterations; i++) {
                        try {
                            x += i;
                        } catch (Exception e) {
                            e.printStackTrace();
                        }
                    }
                    return x;
                }
            }, new Benchmark("no try") {
                @Override int run(int iterations) throws Throwable {
                    int x = 0;
                    for (int i = 0; i < iterations; i++) {
                        x += i;
                    }
                    return x;
                }
            }
        };
        for (Benchmark bm : benchmarks) {
            System.out.println(bm);
        }
    }
}

আমার কম্পিউটারে, এটি এমন কিছু মুদ্রণ করে:

try     0.598 ns
no try  0.601 ns

কমপক্ষে এই তুচ্ছ উদাহরণে, চেষ্টা বিবৃতিটির কার্য সম্পাদনের উপর কোনও পরিমাপযোগ্য প্রভাব ছিল না। আরও জটিল বিষয়গুলি পরিমাপে নির্দ্বিধায়

সাধারণভাবে বলতে গেলে, আমি আপনার কোডটিতে প্রকৃত পারফরম্যান্স সমস্যার প্রমাণ না পাওয়া পর্যন্ত ভাষা নির্মানের পারফরম্যান্স ব্যয় সম্পর্কে চিন্তা না করার পরামর্শ দিচ্ছি। অথবা ডোনাল্ড Knuth করা এটা: "অকাল অপ্টিমাইজেশান সব মন্দ রুট হয়"।


4
যখন বেশিরভাগ জেভিএম-তে চেষ্টা / চেষ্টা করার চেষ্টা একই রকম হয় তবে মাইক্রোব্যাঙ্কমার্ক মারাত্মকভাবে ত্রুটিযুক্ত।
বেটসেস

2
বেশ কয়েকটি স্তর: আপনার মানে ফলাফলগুলি 1ns এর অধীনে গণনা করা হয়েছে? সংকলিত কোড উভয় চেষ্টা / ধরা এবং সম্পূর্ণরূপে লুপটি সরিয়ে ফেলবে (1 থেকে n থেকে সংখ্যার যোগফল একটি তুচ্ছ পাটিগণিত অগ্রগতির যোগফল)। কোডটিতে চেষ্টা থাকলেও / শেষ পর্যন্ত সংকলক প্রমাণ করতে পারে, সেখানে ফেলে দেওয়ার মতো কিছুই নেই। বিমূর্ত কোডটিতে মাত্র 2 টি কল সাইট রয়েছে এবং এটি ক্লোন এবং ইনলাইনড হবে। আরও কিছু মামলা রয়েছে, কেবল মাইক্রোবেঞ্চমার্কের উপর কিছু নিবন্ধগুলি দেখুন এবং এটি আপনি কোনও মাইক্রোব্যাঙ্কমার্ক লেখার সিদ্ধান্ত নেন সর্বদা উত্পন্ন সমাবেশটি পরীক্ষা করুন।
বেটসেস

3
উল্লিখিত সময়গুলি লুপটির পুনরাবৃত্তি হয়। একটি পরিমাপ কেবল তখনই ব্যবহৃত হবে যখন এতে মোট সময় অতিবাহিত হয়েছে> ০.০ সেকেন্ড (বা ২ বিলিয়ন পুনরাবৃত্তি, যা এখানে ছিল না) আমি আপনার দৃtion় প্রতিবাদটি দেখতে পাচ্ছি যে লুপটি পুরোপুরি বিশ্বাস করা মুছে ফেলা হয়েছে - কারণ যদি লুপটি মুছে ফেলা হয়েছে, এক্সিকিউট করতে 0.1 সেকেন্ড কি নিয়েছিল?
মেরিটন

... এবং প্রকৃতপক্ষে, অনুযায়ী -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssemblyলুপ এবং এর সংযোজন উভয়ই উত্পন্ন দেশীয় কোডে উপস্থিত রয়েছে। এবং না, বিমূর্ত পদ্ধতিগুলি অন্তর্ভুক্ত নয়, কারণ তাদের আহ্বানকারী কেবল সময়ের মধ্যে সংকলিত হয় না (সম্ভবত, কারণ এটি যথেষ্ট সময় আহ্বান করা হয়নি)।
মেরিটন

আমি জাভাতে কীভাবে একটি সঠিক মাইক্রো-বেঞ্চমার্ক লিখব: stackoverflow.com/questions/504103/…
ভাদজিম

46

try/ এর catchপারফরম্যান্সে কিছুটা প্রভাব ফেলতে পারে। কারণ এটি জেভিএমকে কিছু অপ্টিমাইজেশন করতে বাধা দেয়। জোশুয়া ব্লচ, "কার্যকর জাভাতে" নিম্নলিখিত বলেছেন:

Try ট্রাই-ক্যাচ ব্লকের ভিতরে কোড স্থাপন করা কিছু নির্দিষ্ট অপটিমেশন বাধা দেয় যা আধুনিক জেভিএম বাস্তবায়ন অন্যথায় সম্পাদন করতে পারে।


24
"এটি জেভিএমকে কিছু অপ্টিমাইজেশন করতে বাধা দেয়" ...? আপনি কি কিছুটা ব্যাখ্যা করতে পারেন?
ক্র্যাকেন

5
@ ট্রাফিক ব্লকের ভিতরে ক্রাকেন কোড (সাধারণত? সর্বদা?) ট্রাই ব্লকগুলির বাইরের কোডের সাথে একটি উদাহরণ হিসাবে পুনরায় অর্ডার করা যায় না।
পাতাসু

3
নোট করুন যে প্রশ্নটি "এটি ব্যয়বহুল" কিনা, "এর পারফরম্যান্সের কোনও প্রভাব আছে কিনা" তা নয়।
mikołak

3
কার্যকর জাভা থেকে একটি অংশ যোগ করা হয়েছে , এবং এটি অবশ্যই জাভা বাইবেল; রেফারেন্স না থাকলে উদ্ধৃতাংশ কিছু না বলে। ব্যবহারিকভাবে জাভাতে কোনও কোড চেষ্টা / শেষ পর্যন্ত কিছু স্তরের মধ্যে।
বেসটসেস

29

হ্যাঁ, অন্যরা যেমন বলেছে, একটি tryব্লক {}চারপাশের চরিত্রগুলি জুড়ে কিছু অপ্টিমাইজেশন বাধা দেয় । বিশেষত, অপ্টিমাইজারটিকে অবশ্যই ধরে নিতে হবে যে ব্লকের মধ্যে যে কোনও সময়ে একটি ব্যতিক্রম ঘটতে পারে, সুতরাং বিবৃতি কার্যকর হওয়ার কোনও নিশ্চয়তা নেই।

উদাহরণ স্বরূপ:

    try {
        int x = a + b * c * d;
        other stuff;
    }
    catch (something) {
        ....
    }
    int y = a + b * c * d;
    use y somehow;

ছাড়া try, নির্ধারিত xহিসাবে গণনা করা মানটি একটি "সাধারণ subexpression" হিসাবে সংরক্ষণ করা যেতে পারে এবং বরাদ্দ করতে পুনরায় ব্যবহার করা হয় y। তবে tryসেখানে কোনও আশ্বাস নেই যে প্রথম অভিব্যক্তিটি কখনও মূল্যায়ন করা হয়েছিল, তাই প্রকাশটি পুনরায় সংশোধন করতে হবে। এটি "স্ট্রেইট-লাইন" কোডে সাধারণত কোনও বড় বিষয় নয়, তবে একটি লুপে তাৎপর্যপূর্ণ হতে পারে।

তবে এটি লক্ষ করা উচিত যে এটি কেবলমাত্র জাইটিসিড কোডে প্রযোজ্য। জাভাক কেবলমাত্র একটি চমকপ্রদ পরিমাণ অপ্টিমাইজেশন করে এবং কোনও tryব্লক প্রবেশ / ছেড়ে দেওয়ার জন্য বাইটকোড দোভাষীকে শূন্য মূল্য দিতে হয় । (ব্লকের সীমানা চিহ্নিত করার জন্য কোনও বাইটকোড তৈরি করা হয়নি))

এবং বেসটেসের জন্য:

public class TryFinally {
    public static void main(String[] argv) throws Throwable {
        try {
            throw new Throwable();
        }
        finally {
            System.out.println("Finally!");
        }
    }
}

আউটপুট:

C:\JavaTools>java TryFinally
Finally!
Exception in thread "main" java.lang.Throwable
        at TryFinally.main(TryFinally.java:4)

জাভাপ আউটপুট:

C:\JavaTools>javap -c TryFinally.class
Compiled from "TryFinally.java"
public class TryFinally {
  public TryFinally();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]) throws java.lang.Throwable;
    Code:
       0: new           #2                  // class java/lang/Throwable
       3: dup
       4: invokespecial #3                  // Method java/lang/Throwable."<init>":()V
       7: athrow
       8: astore_1
       9: getstatic     #4                  // Field java/lang/System.out:Ljava/io/PrintStream;
      12: ldc           #5                  // String Finally!
      14: invokevirtual #6                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      17: aload_1
      18: athrow
    Exception table:
       from    to  target type
           0     9     8   any
}

"গোটো" নেই।


ব্লকের সীমানা চিহ্নিত করার জন্য কোনও বাইটকোড তৈরি করা হয় না এটি অগত্যা নয় - এটি ব্লকটি ছেড়ে যাওয়ার জন্য জিওটিওও প্রয়োজন, অন্যথায় এটি catch/finallyফ্রেমের মধ্যে পড়বে ।
বেটসেস

@ বেস্টেস - এমনকি যদি একটি জিওটিও উত্পন্ন হয় (যা প্রদত্ত নয়) তবে এর ব্যয়টি মিনিস্কুল এবং এটি একটি ব্লকের সীমানার জন্য "চিহ্নিতকারী" হওয়া অনেক দূরে - অনেকগুলি কনস্ট্রাক্টের জন্য গোটো তৈরি করা যেতে পারে।
হট লিকস

আমি কখনই ব্যয়ের কথা উল্লেখ করি নি, তবে কোনও বাইটকোড উত্পন্ন নয় এটি একটি মিথ্যা বক্তব্য। এখানেই শেষ. আসলে, বাইটোকোডে কোনও ব্লক নেই, ফ্রেমগুলি ব্লকের সমান হয় না।
বেটসেস

চেষ্টাটি শেষ পর্যন্ত সরাসরি পড়ে গেলে কোনও গোটো হবে না এবং এমন অন্যান্য পরিস্থিতি রয়েছে যেখানে কোনও জোটো থাকবে না। মুল বক্তব্যটি হ'ল "প্রবেশের চেষ্টা" / "প্রস্থান চেষ্টা" বাইটোকোডের অর্ডারে কিছুই নেই।
হট লিকস

চেষ্টাটি শেষ পর্যন্ত সরাসরি পড়ে গেলে কোনও গোটো হবে না - মিথ্যা! finallyবাইটকোডে কোনও নেই , এটির মধ্যে রয়েছে try/catch(Throwable any){...; throw any;}স্টেটমেন্ট ডাব্লু / ফ্রেম এবং থ্রোয়েবল যে সংজ্ঞায়িত হওয়া উচিত (নন নাল) ইত্যাদি। আপনি কেন বিষয়টি নিয়ে তর্ক করার চেষ্টা করছেন, আপনি কমপক্ষে কিছু বাইকোড পরীক্ষা করতে পারেন? ইমপ্লের জন্য বর্তমান নির্দেশিকা eline অবশেষে ব্লকগুলি অনুলিপি করা এবং গোটো বিভাগ (পূর্ববর্তী ইমপ্ল) এড়ানো হচ্ছে তবে বাইকোডগুলি কয়টি বহির্গমন পয়েন্ট রয়েছে তা নির্ভর করে অনুলিপি করতে হবে।
বেটসেস

8

কেন অপ্টিমাইজেশানগুলি সম্পাদন করা যায় না তা বোঝার জন্য অন্তর্নিহিত প্রক্রিয়াগুলি বোঝার জন্য এটি দরকারী। আমি সর্বাধিক সংক্ষিপ্ত উদাহরণটি সি ম্যাক্রোগুলিতে প্রয়োগ করা হয়েছিল: http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html

#include <stdio.h>
#include <setjmp.h>
#define TRY do{ jmp_buf ex_buf__; switch( setjmp(ex_buf__) ){ case 0: while(1){
#define CATCH(x) break; case x:
#define FINALLY break; } default:
#define ETRY } }while(0)
#define THROW(x) longjmp(ex_buf__, x)

কোনও জাম্পকে X, Y এবং Z এ স্থানীয়করণ করা যায় কিনা তা নির্ধারণ করতে প্রায়শই সংকলনকারীদের সমস্যা হয় তাই তারা সুরক্ষিত হওয়ার গ্যারান্টি দিতে পারে না এমন অপ্টিমাইজেশন এড়িয়ে যায়, তবে বাস্তবায়ন নিজেই বরং হালকা।


4
এই সি ম্যাক্রোগুলি আপনি চেষ্টা / ধরার জন্য খুঁজে পেয়েছেন তা জাভা বা সি # বাস্তবায়নের সমতুল্য নয়, যা 0 রান সময় নির্দেশিকা নির্গত করে।
পাতাসু

জাভা বাস্তবায়ন সম্পূর্ণরূপে অন্তর্ভুক্ত করার পক্ষে অত্যন্ত বিস্তৃত, কীভাবে ব্যতিক্রমগুলি বাস্তবায়ন করা যায় তার মূল ধারণাটি বোঝার উদ্দেশ্যে এটি একটি সরল বাস্তবায়ন। এটি 0 রান টাইম নির্দেশাবলী বহন করে তা বিভ্রান্তিকর বলে। উদাহরণস্বরূপ একটি সাধারণ শ্রেণিবদ্ধকরণটি রানটাইম এক্সসেপশনকে প্রসারিত করে যা ব্যতিক্রমগুলি প্রসারিত করে যা থ্রোয়েবল প্রসারিত করে যার মধ্যে রয়েছে: গ্রেপকোড / ফাইল / রিপোসিটরি . grepcode.com/java/root/jdk/openjdk/… ... এটি সিতে স্যুইচ-কেস বলার মতো like বিনামূল্যে যদি কেবলমাত্র 1 টি কেস ব্যবহৃত হয়, তবুও একটি ছোট স্টার্টআপ ওভারহেড থাকবে।
টেকনোসরাস

1
@ পাতাসু এই সমস্ত পূর্বনির্ধারিত বিটগুলি এখনও ব্যবহৃত হয় কি না তা শুরুতে লোড করতে হবে। সংকলনের সময় রান সময় মেমরির ব্যতিক্রম আছে কিনা তা জানার কোনও উপায় নেই - এ কারণেই তাদের রান টাইম ব্যতিক্রম বলা হয় - অন্যথায় তারা সংকলক সতর্কতা / ত্রুটিযুক্ত হবে, তাই এটি সমস্ত কিছুকে অপ্টিমাইজ করে না , তাদের পরিচালনা করার জন্য সমস্ত কোড সংকলিত কোডের অন্তর্ভুক্ত এবং একটি প্রারম্ভিক ব্যয়।
টেকনোসরাস

2
আমি সি # ও জাভা সম্পর্কে বলতে পারি না, কোড নয়, মেটাডেটা যুক্ত করে চেষ্টা করা হয়। যখন কোনও চেষ্টা ব্লক প্রবেশ করা হয়, তখন এটি নির্দেশ করার জন্য কিছুই কার্যকর করা হয় না - যখন কোনও ব্যতিক্রম নিক্ষেপ করা হয়, তখন স্ট্যাকটি খালি করা হয় না এবং মেটাডেটা সেই ব্যতিক্রমের হ্যান্ডলারের জন্য পরীক্ষা করা (ব্যয়বহুল)।
পাতাসু

1
হ্যাঁ, আমি আসলে একটি জাভা ইন্টারপ্রেটার এবং স্ট্যাটিক বাইটকোড সংকলক বাস্তবায়ন করেছি এবং পরবর্তী জেআইটিসিতে (আইবিএম আইসারিগুলির জন্য) কাজ করেছি এবং আমি আপনাকে বলতে পারি যে বাইটোকোডগুলিতে ট্রান্স রেঞ্জের প্রবেশ / প্রস্থান "চিহ্ন" কিছুই নেই, বরং ব্যাপ্তিগুলি একটি পৃথক সারণীতে চিহ্নিত করা হয়। দোভাষী তার চেষ্টা পরিসরের জন্য বিশেষ কিছু করেন না (যতক্ষণ না একটি ব্যতিক্রম উত্থাপিত না হয়)। একটি জেআইটিসি (বা স্ট্যাটিক বাইটকোড সংকলক) পূর্বে উল্লিখিত হিসাবে অপ্টিমাইজেশন দমন করতে সীমানা সম্পর্কে সচেতন হতে হবে।
হট লিকস

8

তবুও আরেকটি মাইক্রোব্যাঙ্কমার্ক ( উত্স )।

আমি একটি পরীক্ষা তৈরি করেছি যাতে আমি ব্যতিক্রম শতাংশের ভিত্তিতে চেষ্টা-ধরা এবং কোনও-চেষ্টা-কোড কোড সংস্করণ পরিমাপ করি। 10% শতাংশ মানে পরীক্ষার 10% ক্ষেত্রে শূন্য ক্ষেত্রে বিভাজন ছিল। একটি পরিস্থিতিতে এটি চেষ্টা-ব্লক দ্বারা পরিচালনা করা হয়, অন্যটিতে শর্তসাপেক্ষ অপারেটর। এখানে আমার ফলাফলের সারণীটি দেওয়া হল:

OS: Windows 8 6.2 x64
JVM: Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 23.25-b01
শতাংশ | ফলাফল (চেষ্টা করুন / যদি, এনএস)   
    0% | 88/90   
    1% | 89/87    
    10% | 86/97    
    90% | 85/83   

যা বলে যে এই মামলার যে কোনওটির মধ্যে উল্লেখযোগ্য পার্থক্য নেই।


3

আমি নুলপয়েন্ট ধারণাটি বেশ ব্যয়বহুল পেয়েছি। 1.2 কে অপারেশনের জন্য সময়টি 200 মিমি এবং 12 মিমি ছিল যখন আমি এটি একইভাবে হ্যান্ডেল করি if(object==null)যা দিয়ে আমার জন্য বেশ উন্নতি হয়েছিল।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.