Node.js ve .Net performansı karşılaştırması


183

Node.js'nin hızlı olması ve büyük miktarda yük alabilmesi hakkında çok şey okudum. Herkes, özellikle .Net vs diğer çerçeveler ile ilgili herhangi bir gerçek dünya kanıt var mı? Okuduğum makalelerin çoğu anekdottur veya .Net ile karşılaştırması yoktur.

Teşekkürler


1
Ne tür bir senaryoda konuştuğumuz konusunda daha açık olabilir misiniz?
Marcus Granström

1
IIS'de çalışan benzer web uygulamaları için .Net ve Node.js'nin herhangi bir performans karşılaştırmasıyla ilgileniyorum.
David Merrilees

1
Kimse yüksek perf bir web sitesi inşa düşünemiyorum. .Net dışındaki gereksinimler. Karşılaşacağınız en temel sorun, yüksek performanstan beri lisanslama açısından çok uygun maliyetli olmayacağıdır. siteler genellikle ölçeklendirme gerektirir. Ve hayır .Net düşmanı değilim. Net faturaları öder.
Shane Courtrille

4
Düğüm / ekspres / mongo ve yeni .net webapi / mongo kullanarak küçük bir REST API'nin dahili testlerini yapmak zorunda kaldım ve müşterinin ne istediğine bağlı olarak mükemmel farklılıklar vardı, ancak günün sonunda, farkı. Kendi senaryolarınıza göre kendi testlerinizi geliştirmeniz gerekir. Farklı API'ların her iki dilde de yazılması üç gün, ardından da testin doğru şekilde yapılması birkaç gün daha sürdü. Uzaktan ciddi bir şey yapmayı planlıyorsanız, gereksinimlerinize göre testler yapmanızı ve yükünüz için hangisinin daha iyi olduğuna kendiniz karar vermenizi öneririm.
AlexGad

5
@ShaneCourtrille .Net (bir çerçeve) ve Windows (bir işletim sistemi) karıştırıyorsunuz. Çok farklı şeyler ve .Net (Linux'ta Mono olarak oldukça güzel çalışan) için lisanslama gereksinimleri YOKTUR.
rainabba

Yanıtlar:


367

HIZLI olmak ve çok fazla LOAD kullanmak iki farklı şeydir. Saniyede bir istekte bulunmak için HIZLI olan bir sunucu, saniyede 500 istek ( LOAD altında ) gönderirseniz tamamen dolandırıcı olabilir .

Ayrıca, statik (ve önbelleğe alınmış) ve dinamik sayfaları karşılaştırmanız gerekir. Statik sayfalardan endişe ediyorsanız, IIS çekirdek modu önbelleklemesi kullandığından IIS muhtemelen düğümü yenecektir, bu da statik bir sayfa isteyen isteklerin çekirdekten bile çıkmayacağı anlamına gelir.

ASP.NET ve düğüm arasında bir karşılaştırma aradığınızı tahmin ediyorum. Bu savaşta, her şey derlendikten / yorumlandıktan sonra muhtemelen performansta oldukça yakın olacaksınız. Belki .NET biraz DAHA HIZLI ya da belki düğüm biraz DAHA HIZLI , ama muhtemelen umursamayacağınız kadar yakın. .NET'e bahse girerdim, ama kesin olarak bilmiyorum.

Düğümün gerçekten zorlayıcı olduğu yer LOAD ile çalışmaktır . Teknolojilerin gerçekten farklı olduğu yer burası. ASP.NET her istek için bir iş parçacığı kendi iş parçacığı havuzundan ayırır ve ASP.NET kullanılabilir tüm iş parçacığı istekleri sıraya alınmaya başlar. @Shankar tarafından verilen örnek gibi "Hello World" uygulamalarını sunuyorsanız, iş parçacığı engellenmeyeceği ve sizden önce birçok isteği işleyebileceğiniz için bu çok önemli olmayabilir. iş parçacığı bitmek. ASP.NET modelinde sorun, iş parçacığını engelleyen G / Ç istekleri yapmaya başladığınızda gelir (bir DB'ye çağrı yapın, bir servise http isteği gönderin, diskten bir dosya okuyun). Bu engelleme istekleri, iş parçacığı havuzundan değerli iş parçacığının hiçbir şey yapmadığı anlamına gelir. Ne kadar fazla engellemeniz varsa, , ASP.NET uygulamanızın YÜKLENMESİ için kullanılabilir.

Bu engellemeyi önlemek için, yanıt beklerken bir iş parçacığının tutulması gerekmeyen G / Ç tamamlama bağlantı noktalarını kullanırsınız. ASP.NET bunu destekler, ancak maalesef .NET DON'T'deki ortak çerçevelerin / kitaplıkların çoğu. Örneğin, ADO.NET, G / Ç tamamlama bağlantı noktalarını destekler, ancak Entity Framework bunları kullanmaz. Böylece tamamen eşzamansız olan ve çok fazla yük işleyen bir ASP.NET uygulaması oluşturabilirsiniz, ancak çoğu insan senkronize olanı oluşturmak kadar kolay olmadığı ve en sevdiğiniz parçalardan bazılarını kullanamayabileceğiniz için yapmaz. (eğer linq to entities gibi) yapıyorsanız.

Sorun, ASP.NET'in (ve .NET Framework'ün) zaman uyumsuz G / Ç hakkında görüş bildirilmek üzere oluşturulmamış olmasıdır. .NET, eşzamanlı veya eşzamansız kod yazmanız umurunda değildir, bu nedenle bu kararı vermek geliştiriciye bağlıdır. Bunun bir parçası, eşzamansız işlemlerle iş parçacığı ve programlamanın "zor" olduğu düşünülmesidir ve .NET herkesi mutlu etmek istemiştir (noobs ve uzmanlar). Daha da zorlaştı çünkü .NET async yapmak için 3-4 farklı desenle sonuçlandı. .NET 4.5, geriye dönüp async IO etrafında fikirli bir model oluşturmak için .NET çerçevesini güçlendirmeye çalışıyor, ancak önem verdiğiniz çerçeveler gerçekten destekleyene kadar biraz zaman alabilir.

Düğüm tasarımcıları ise ALL I / O'nun async olması gerektiği konusunda fikirli bir seçim yaptılar. Bu karar nedeniyle, düğüm tasarımcıları aynı zamanda her bir düğüm örneğinin iş parçacığı geçişini en aza indirgemek için tek iş parçacıklı olacağına ve bir iş parçacığının yalnızca kuyruğa alınmış kodu yürüteceğine karar verebildiler. Bu yeni bir istek olabilir, bir DB isteğinden geri arama olabilir, yaptığınız bir http dinlenme isteğinden geri arama olabilir. Düğüm, iş parçacığı bağlam anahtarlarını ortadan kaldırarak CPU verimliliğini en üst düzeye çıkarmaya çalışır. Düğüm, TÜM G / Ç'nin eşzamansız olduğu konusunda bu görüşlü seçimi yaptığı için, tüm çerçeveleri / eklentileri bu seçimi desteklediği anlamına gelir. Düğüme% 100 eşzamansız uygulamalar yazmak daha kolaydır (çünkü düğüm sizi eşzamansız uygulamalar yazmaya zorlar).

Yine, şu ya da bu şekilde kanıtlamak için zor sayılar yok, ancak düğümün tipik web uygulaması için LOAD yarışmasını kazanacağını düşünüyorum. Yüksek düzeyde optimize edilmiş (% 100 eşzamansız) bir .NET uygulaması, eşdeğer node.js uygulamasına parası için bir çalışma verebilir, ancak tüm .NET ve tüm düğüm uygulamalarının ortalamasını aldıysanız, ortalama düğüm muhtemelen daha fazla YÜK.

Umarım yardımcı olur.


39
ASP.NET'in zaman uyumsuz istek işleyicilerini uzun süredir desteklediğini ve MVC4 ile kullanımı son derece basit hale geldiğini unutmayın.
fabspro

12
"Bu engelleme istekleri, iş parçacığı havuzundan değerli iş parçacığının hiçbir şey yapmadığı anlamına gelir. Ne kadar çok engelleme olursa, ASP.NET uygulamanızın YÜKLENMESİ o kadar az hizmet verebilir." Ön tarafta (gelen istek) veya arka uçta (asıl iş parçacığı) sıraya girmemiz neden önemlidir? Ne olursa olsun, müşteri talebi yanıtı bekliyor. İnsanların bu tartışmada göz ardı etmesinin anahtarı "Verim" dir. Bir sunucunun kaç eşzamanlı bağlantıya sahip olduğu değil, her talebe ne kadar hızlı yanıt verebileceği doğru değil mi?
sjdirect

19
// Yorumumu düzenlememe izin vermeyeceğim, işte söylemek istediğim şey bu .// @sjdirect - İşlem hacmi, yanıt süresiyle aynı değil. Yanıt süresine önem vermekte haklısınız, ancak kuyruk zamanı + yanıt süresi veya sadece yanıt süresi arasında bir seçim. İsteğin işlenmesi her iki senaryoda da sürecektir (Eşzamanlı yürütme, DB isteğinizin daha hızlı yürütülmesini sağlamayacaktır), ancak istek iş parçacıklarınız engellendiyse, isteklere de kuyruk zamanı eklersiniz çünkü önceki istekler yerine getirilinceye kadar isteği işlemeye başlayamazsınız.
Matt Dotson

6
Bu gerçekten bilgilendiriciydi, teşekkürler! Dikkat edilmesi gereken bir şey, Entity Framework 6'nın (şu anda RC1) artık .NET 4.5'ten eşzamansız kalıbı desteklemesidir. msdn.microsoft.com/en-us/data/jj819165
parlamento

4
Bu çok spekülatif! Verilere sahip olmak harika olurdu. Performans konularına nasıl devam edeceğime genellikle böyle karar veririm.
kingPuppy

50

Düğümler ve IIS arasında temel bir performans testi yaptım. IIS, "merhaba, dünya!" Aşağıdaki kod.

donanımım: Dell Latitude E6510, Core i5 (çift çekirdekli), 8 GB RAM, Windows 7 Enterprise 64 bit İşletim Sistemi

düğüm sunucusu

runs at http://localhost:9090/
/// <reference path="node-vsdoc.js" />
var http = require("http");
http.createServer(function (request, response) {
response.writeHead(200, { "Content-Type": "text/html" });
response.write("<p>hello, world!</p>");
response.end();
}).listen(9090);

default.htm'dir

hosted by iis at http://localhost/test/
<p>hello, world!</p>

Görev paralel kütüphanesini kullanarak kendi karşılaştırma programım:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Net;
using System.Threading;
using System.Threading.Tasks;
using System.Diagnostics;

namespace HttpBench
{
class Program
{
    private int TotalCount = 100000;
    private int ConcurrentThreads = 1000;
    private int failedCount;
    private int totalBytes;
    private int totalTime;
    private int completedCount;
    private static object lockObj = new object();

    /// <summary>
    /// main entry point
    /// </summary>
    static void Main(string[] args)
    {
        Program p = new Program();
        p.Run(args);
    }

    /// <summary>
    /// actual execution
    /// </summary>
    private void Run(string[] args)
    {
        // check command line
        if (args.Length == 0)
        {
            this.PrintUsage();
            return;
        }
        if (args[0] == "/?" || args[0] == "/h")
        {
            this.PrintUsage();
            return;
        }

        // use parallel library, download data
        ParallelOptions options = new ParallelOptions();
        options.MaxDegreeOfParallelism = this.ConcurrentThreads;
        int start = Environment.TickCount;
        Parallel.For(0, this.TotalCount, options, i =>
            {
                this.DownloadUrl(i, args[0]);
            }
        );
        int end = Environment.TickCount;

        // print results
        this.Print("Total requests sent: {0}", true, this.TotalCount);
        this.Print("Concurrent threads: {0}", true, this.ConcurrentThreads);
        this.Print("Total completed requests: {0}", true, this.completedCount);
        this.Print("Failed requests: {0}", true, this.failedCount);
        this.Print("Sum total of thread times (seconds): {0}", true, this.totalTime / 1000);
        this.Print("Total time taken by this program (seconds): {0}", true, (end - start) / 1000);
        this.Print("Total bytes: {0}", true, this.totalBytes);
    }

    /// <summary>
    /// download data from the given url
    /// </summary>
    private void DownloadUrl(int index, string url)
    {
        using (WebClient client = new WebClient())
        {
            try
            {
                int start = Environment.TickCount;
                byte[] data = client.DownloadData(url);
                int end = Environment.TickCount;
                lock (lockObj)
                {
                    this.totalTime = this.totalTime + (end - start);
                    if (data != null)
                    {
                        this.totalBytes = this.totalBytes + data.Length;
                    }
                }
            }
            catch
            {
                lock (lockObj) { this.failedCount++; }
            }
            lock (lockObj)
            {
                this.completedCount++;
                if (this.completedCount % 10000 == 0)
                {
                    this.Print("Completed {0} requests.", true, this.completedCount);
                }
            }
        }
    }

    /// <summary>
    /// print usage of this program
    /// </summary>
    private void PrintUsage()
    {
        this.Print("usage: httpbench [options] <url>");
    }

    /// <summary>
    /// print exception message to console
    /// </summary>
    private void PrintError(string msg, Exception ex = null, params object[] args)
    {
        StringBuilder sb = new System.Text.StringBuilder();
        sb.Append("Error: ");
        sb.AppendFormat(msg, args);
        if (ex != null)
        {
            sb.Append("Exception: ");
            sb.Append(ex.Message);
        }
        this.Print(sb.ToString());
    }

    /// <summary>
    /// print to console
    /// </summary>
    private void Print(string msg, bool isLine = true, params object[] args)
    {
        if (isLine)
        {
            Console.WriteLine(msg, args);
        }
        else
        {
            Console.Write(msg, args);
        }
    }

}
}

ve sonuçlar:

IIS: httpbench.exe http://localhost/test

Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 97
Total time taken by this program (seconds): 16
Total bytes: 2000000

nodejs: httpbench.exe http://localhost:9090/

Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 234
Total time taken by this program (seconds): 27
Total bytes: 2000000

Sonuç: IIS, düğümlerden 2,5 kat daha hızlıdır (Windows'ta). Bu çok basit bir testtir ve hiçbir şekilde kesin değildir. Ama bunun iyi bir başlangıç ​​noktası olduğuna inanıyorum. Nodejs muhtemelen diğer web sunucularında, diğer platformlarda daha hızlıdır, ancak Windows IIS'de kazanan budur. ASP.NET MVC'lerini düğümlere dönüştürmek isteyen geliştiriciler, duraklamadan ve devam etmeden önce iki kez düşünmelidir.

Güncellenmiş (17.05.2012) Tomcat (pencerelerde), statik html'yi yerleştirirken IIS'yi IIS'den yaklaşık 3 kat daha hızlı yendi.

erkek kedi

index.html at http://localhost:8080/test/
<p>hello, world!</p>

tomcat sonuçları

httpbench.exe http://localhost:8080/test/
Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 31
Total time taken by this program (seconds): 5
Total bytes: 2000000

güncellenmiş sonuç: Ben kıyaslama programı birden çok kez çalıştırdı. Tomcat, WINDOWS'da STATIC HTML'yi hazırlarken en hızlı sunucu gibi görünüyor.

Güncelleme (18.05.2012) Daha önce 10.000 eşzamanlı istek ile 100.000 toplam istek vardı. Toplam 1.000.000 talebi ve 100.000 eşzamanlı talebi arttırdım. IIS çığlık atan kazanan olarak ortaya çıkıyor ve Nodejs en kötüsünü işliyor. Aşağıdaki sonuçları tablo haline getirdim:

WINDOWS'da STATIC HTML sunan NodeJS ve IIS ve Tomcat.


56
Elmaları kedilerle karşılaştırıyorsunuz. Node.js'yi ASP.NET MVC ile karşılaştırın. En fazla IIS statik dosyaları sunmakta daha hızlıdır, ancak ben bile bundan ciddi olarak şüpheliyim.
alessioalex

12
@alessioalex: Bu karşılaştırmanın neden geçerli olmadığını anlamıyorum. statik html için yanıt sürelerini karşılaştırıyorum. IIS, default.htm dosyasının statik html'sini hazırlarken, nodejs sunucusu aynı dizeyi çıkarır ve IIS öne çıkar. Bir ASP.NET MVC uygulamasını karşılaştırmak daha fazla çaba ve zaman gerektirecektir ve daha sonra yapmayı planlıyorum.
Shankar

28
Tamam, IIS'nin Windows'ta statik dosyaları sunma konusunda Düğümden daha iyi olduğunu varsayalım. IIS yalnızca statik dosyalar sunar ve Apache veya NGINX gibi Düğüm bundan çok daha fazlasını yapar. ASP.NET MVC'yi Düğüm ile karşılaştırmalısınız (veritabanını sorgulama, harici bir hizmetten veri alma, vb.). ASP.NET MVC üzerinden Node ile büyük performans artışları göreceksiniz.
alessioalex

27
Bunu yapacaksanız, lütfen en azından düğümün doğasını anlayın. Bir Düğüm işlemi yalnızca tek bir çekirdek kullanabilir. Yani, karşılaştırdığınız şey, bir çekirdek üzerinde çalışan bir düğüm işlemidir ve birden çok çekirdek kullanan bir IIS ve tomcat işlemidir. Düzgün karşılaştırmak için, kümelenmiş düğümü çalıştırmanız gerekir. Kullanımı kolay bir küme çözümü için nodejs.org/api/cluster.html adresine bakın . Ancak, deneyimden anlatabilirim, düğüm ve async c # arasındaki fark, yaptığınız şeye bağlı olarak her iki şekilde% 10-15'dir.
AlexGad

14
Ayrıca, düğüm, IIS ve Tomcat ile statik dosyaları test etmek anlamsızdır. Her şeyden önce, düğüm statik dosyalar için harika değildir, ancak gerçekten olması amaçlanmamıştır (doğru iş için doğru aracı kullanın). Birisi statik dosyalarının hızı konusunda endişeli ise, yine de bir CDN kullanıyor olmalıdır.
AlexGad

26

NIO sunucuları (Node.js vb.) BIO sunucularından daha hızlı olma eğilimindedir. (IIS vb.). İddiamı desteklemek için TechEmpower, web çerçevesi karşılaştırmaları konusunda uzmanlaşmış bir şirkettir . Çok açıktır ve tüm çerçeveleri test etmenin standart bir yoluna sahiptirler.

9. Tur testleri şu anda en sonuncudur (Mayıs 2014). Test edilen birçok IIS lezzeti var, ancak aspnet soyulmuş en hızlı IIS varyantı gibi görünüyor.

Saniyelerdeki yanıtlardaki sonuçlar (daha yüksek daha iyidir):

  • JSON Serileştirmesi
    • nodejs: 228,887
    • aspnet soyulmuş: 105,272
  • Tek Sorgu
    • nodejs-mysql: 88,597
    • aspnet soyulmuş ham: 47,066
  • Birden Çok Sorgu
    • nodejs-mysql: 8,878
    • aspnet soyulmuş ham: 3,915
  • Düz Metin
    • nodejs: 289,578
    • aspnet soyulmuş: 109,136

Her durumda, Node.js IIS'den 2x + daha hızlı olma eğilimindedir.


1
ASPNET'in en iyi njs girişi olan nodejs-mysql'yi yenen iki girişi (aspnet stripped-raw ve aspnet-mysql-raw) olduğu Birden Çok Sorgu testi dışında.
GalacticCowboy

4
Çoklu Sorgu testi, sunucu hızını tam olarak test etmiyor. Esas olarak MySQL sürücü hızını test ediyor. NodeJS esas olarak MongoDB, CouchDB gibi NO-SQL veritabanlarını kullanır. MySQL sürücüsü optimize edilmemiş olabilir. Json serileştirme ve Plaintext testleri saf sunucu hızını verme eğilimindedir - onlara daha fazla güvenirim.
ttekin

IIS düğümünü kullanırsam ne olur? performansım düşecek ya da aynı olacak.
Umashankar

3
Karşılaştırma sayfasına bağlantı için teşekkürler. Ancak cevabın güncellenmesi gerekebilir, .NET Core 2.1'in ortaya çıkmasıyla işler biraz değişmiş olabilir. Örneğin, 2018 JSON serileştirme karşılaştırması, 971.122 istek / sn'de ASP.NET Core'u ve 561.593 istek / sn'de Node.js'yi listelemektedir, bu nedenle bugün ASP.NET Core bu açıdan Node.js'den neredeyse iki kat daha hızlı görünmektedir.
stakx -

13

Burada senaryo çok önemli olan Marcus Granstrom ile aynı fikirdeyim.

Dürüst olmak gerekirse, yüksek bir mimari karar aldığınız anlaşılıyor. Benim tavsiyem endişe alanlarını izole etmek ve düşündüğünüz yığınlar arasında bir "fırında" yapmak olacaktır.

Günün sonunda bu karardan siz sorumlusunuz ve "Stackoverflow'daki bir adam bana iyi olacağını söyleyen bir makale gösterdi" bahanesini patronunuzla keser diye düşünmüyorum.


1
İnsanları ikna edecek bir şey arıyorum (patronum dahil), bir MVC.net web sitesine alternatif olarak düşünmeye değer, onları değiştirmemiz gerektiğine ikna etmek değil. Şimdiye kadar bulduğum tek şey, daha fazla yükü destekleyebileceği ve daha iyi performans gösterebileceği anekdotlardan bahsediyor. Bunu gerçekten kanıtlayan var mı?
David Merrilees

17
Ama MVC web sitesinde yanlış olan ne? NEDEN bir alternatif bulmaya çalışıyorsun? Bu en önemli Q. Eğer sorun ağır eşzamanlı yük altında köpek yavaş ise, o zaman async.net kullandığınızdan emin olmalısınız. Hala gerçekten yavaşsa, kodunuzu kırmanız ve darboğazlarınızın nerede olduğunu bulmanız gerekir. Deneyimlerime göre, GERÇEK DÜNYA senaryolarında düğüm ve zaman uyumsuz ağ arasında büyük bir fark yok. Platformunuzu değiştirebilirsiniz, ancak başka bir kod darboğazı / baş ağrısı kümesi için muhtemelen bir kod darboğazını / baş ağrısını değiştirmeniz yeterlidir.
AlexGad

1

Gördüğüm temel fark, .js düğümü dinamik programlama dilidir (tip kontrolü), bu yüzden türler çalışma zamanında türetilmiş olmalıdır. C # .NET gibi güçlü yazılan diller, özellikle pahalı hesaplama olduğunda, Düğüm .js (ve PHP vb.) İle mücadeleyi teorik olarak çok daha fazla potansiyele sahiptir. Bu arada, .NET C / C ++ ile düğüm .js'den daha iyi yerel birlikte çalışabilir olmalıdır.


4
JS'deki "zayıf" yazmanın onu yavaşlatması ve yanlış ve alakasız olması önerisine göre, Elma ve Taşları karşılaştırırsınız (Portakal bile önerdiğinizden daha benzer olacaktır).
rainabba

7
@rainabba Bir çeşit hesaplamayı karşılaştırdığınızda (örneğin, x'in fibonacci'si) tamamen doğrudur.
Stan

5
@steve Aslında, Z verildiğinde hala söyleyemezsiniz çünkü JS bir dil ve .Net bir çerçevedir. Bunlar tamamen farklı şeyler. Net çalışma zamanları belirli bir işlemci mimarisi için derlenmiştir ve bu nedenle tek bir donanım parçası için belirli bir kod parçasının performansını önemli ölçüde değiştiremezsiniz. V8'in gösterdiği gibi, JS yorumlanabilir ve yürütülebilir ve son derece değişken hızlarda olabilir ve bir gün JS'de yazılmış fibonacci kodunuzun CLR üzerinden çalıştırılan kod kadar hızlı çalışmadığını düşünmek için bir neden yoktur (büyük olasılıkla, Daha hızlı). Elma ve Taşlar; söylediğim gibi.
rainabba

1
haklı olabilirsiniz, ancak benim görüşüme göre, diğer ülkeleri bilmiyorum, Çin'de, az önce bilinen EF veya Linq to Sql ile görüştüğüm birçok programcı, bu çerçeveler
.net'in

1
Aynı şey JS için de söylenebilir. JS fibonacci'yi yakalarken, .NET'in beklediği yerde kalacağını düşünüyor musunuz?
quanben
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.