aprile 2005 - Posts
Ho appena perso un paio d'ore per trovare un bug in questa funzione:
public static InheritedCost operator - ( InheritedCost a ) {
return new InheritedCost( -a.Last, a.Inherited );
}
La versione corretta è questa:
public static InheritedCost operator - ( InheritedCost a ) {
return new InheritedCost( -a.Last, -a.Inherited );
}
Tanto per essere chiari: il codice è mio, il responsabile sono io. Il programma (anzi il componente!) esaminato non ha unit testing (non è molto recente). Se mai ve ne fosse bisogno, questa è un'ulteriore lezione da trarre: lo unit testing non fa aumentare i tempi di sviluppo, li fa diminuire, sempre che si guardi la cosa dal punto di vista del tempo totale (analisi + codifica + debug + manutenzione per richieste modifiche) e non limitandosi al tempo necessario per arrivare alla Beta 1.
Questo bug ha richiesto ore perché causava un problema nel risultato finale di un'elaborazione estremamente lunga e complessa che poteva avere altre decine di spiegazioni tutte plausibili, anche aritmeticamente (un caso particolare di applicazione della legge di Murphy). Poiché si tratta di un operatore in overload, non era mai stato usato fino a poche settimane fa, e solo adesso i nodi vengono al pettine.
Bene, se mai ve ne fosse stato bisogno, io la lezione l'ho imparata (non che non la sapessi già, ma non avevo mai applicato lo unit testing ai progetti più vecchi già realizzati). Programmatore avvisato...
Mark Russinovich racconta come ha individuato un bug (o forse due) di MSN Desktop Search usando Process Explorer.
Segnalo il post più che altro perché suggerisce come usare le funzioni Find disponibili: devo ammettere che non avevo ancora realizzato che tali funzioni lavorano sul nome assegnato agli oggetti kernel, che nel caso dei file corrisponde al nome completo del file. Bisogna abituarcisi, è molto potente.
La domanda che pongo nel titolo di questo post è il riassunto del post di Francesco Quaratino che ho letto stasera. Stavo per rispondere con un commento ma la lunghezza della risposta mi ha suggerito di dedicare un intero post all'argomento. In sintesi, Francesco si chiede se ha ancora senso acquistare (e leggere) riviste dedicate all'IT.
Io continuo a comprare alcune riviste. Alla fine però MSDN Magazine e SQL Server Magazine sono le due che leggo di più. PocketPC Magazine è un piacevole passatempo (vedi un sacco di gadget nuovi). PC Professionale per avere un'idea di cosa c'è di nuovo sull'hardware (anche se ultimamente lo spazio occupato dalle macchine digitali è enorme).
Sono abbonato ad altre riviste (italiane e straniere) ma spesso dopo un'occhiata al sommario non trovo molto che stuzzichi l'attenzione. Una menzione particolare però devo farla a .NET Developer's Journal, che non eccelle per gli articoli strettamente tecnici ma dove ho letto eccellenti interviste ed editoriali molto interessanti.
Il problema è anche questo: scrivere è un'attività faticosa e mal remunerata. In Italia, poi, il discorso si estremizza. Inevitabile quindi che chi non può fare a meno di scrivere lo faccia per grosse testate americante, e chi vuole pubblicare in Italia faccia fatica a trovare chi scrive, visti i compensi.
Io ho sempre pensato che in Italia ci sarebbe posto per una rivista dedicata all'IT (sviluppatori e sistemisti) ad alto livello, ma dovrebbe farla un editore "importante", che però con i numeri di questo genere di riviste probabilmente non alza nemmeno un telefono.
Una rivista, poi, per i tempi tecnici, non può puntare all'ultima moda del momento, ma è il luogo ideale dove ragionare a mente fredda. Un senso ce l'ha ancora. La rivista non la leggo quando sono al PC, infatti leggo più volentieri gli articoli più teorici che non quelli più da "smanettiamo sul codice". Per fare un esempio, Don Box è uno che quando scrive, per come scrive, non richiede che tu sia alla tastiera, anche se parla di dettagli molto tecnici. Alla fine la qualità conta.
Cerco di riassumere i miei pensieri illustrandoti la sequenza di escalation ideale di un problema: se ho un presunto bug o devo capire meglio in che modo di usare un componente/libreria, cerco sui newsgroup; se devo usare un componente/libreria per la prima volta, cerco un articolo (se l'help non è sufficiente) e un articolo o un blog spesso sono risolutivi; se invece devo accostarmi a concetti nuovi o voglio degli approfondimenti anche teorici, probabilmente devo cercare una rivista o un libro, qualche volta trovo un articolo ma poi subentra la potenziale difficoltà di lettura (al PC si è sempre un po' dispersivi).
Morale (mia): la rivista continua ad avere senso, solo dovrebbe tarare i contenuti in base all'uso che se ne fa.
La notizia è che il TechEd 2005 a Orlando è esaurito (sold out, come si dice). La vera notizia è che è esaurito oltre 45 giorni prima dell'inizio della conferenza (5 giugno 2005).
Spesso ho pensato (e non ero il solo) che il cartello "sold out" venisse appeso al sito pochi giorni prima dell'evento proprio per gonfiare la cosa. Oggi mi trovo a pensare che forse hanno fatto delle stime di affluenza fin troppo conservative (infatti c'è già una lista di attesa, non appena definiscono gli accordi con il centro congressi per allargare lo spazio).
Al di là dei pensieri malevoli, però, resta il fatto di un'alta affluenza a conferenze tecniche a pagamento oltreoceano. Dato in controtendenza rispetto a quanto avviene in Europa ma soprattutto a quanto avviene in Italia. Noi (DevLeap) abbiamo scelto di puntare a piccoli eventi più mirati e specializzati, per giustificare più facilmente il rapporto costi-benefici per i partecipanti (sempre che si tratti di eventi a pagamento, perché spesso facciamo eventi gratuiti come il prossimo FWC 2005).
Una ragione può essere il costo: negli USA il TechEd costa 1.695$ (iscrizione prima del 15 aprile, ma praticamente finora si sono iscritti tutti così); per andare al TechEd 2005 di Amsterdam bisogna invece spendere 1.950€ (prima del 20 maggio, che diventano 2.250€ dopo tale data). A cui bisogna aggiungere l'IVA del 19% (non deducibile per chi ha partita IVA in Italia, spero di non sbagliarmi...) che portano il tutto a 2.320€ nel caso migliore. Al cambio attuale andare a Orlando costerebbe (costava) 1.300€ circa, con 1.000€ ci si paga abbondantemente un biglietto aereo dall'Italia (ok, non in business) senza contare che per andare ad Amsterdam un aereo bisogna pur prenderlo e non è gratis. E senza contare che qualitativamente e quantitativamente (in senso tecnico, almeno) il TechEd americano è meglio di quello europeo. Anche con un cambio "alla pari", farei lo stesso discorso.
Chi fa ragionamenti semplicistici, poi, punta il dito alla crescita economica in atto negli USA contrapposta a una situazione decisamente peggiore in Italia e in Europa. Se questo può valere per i massimi sistemi, non è sempre applicabile a casi specifici: io resto dell'idea che il prodotto è una cosa importante e se un prodotto è valido, i professionisti lo comprano. Diciamo che nessuno ha più soldi da gettare, ma da investire forse sì (con le dovute eccezioni, certo).
Negli ultimi due anni (2003 e 2004) sono stato al TechEd europeo e ho visto molti italiani: segno che la barriera linguistica non è più un ostacolo così grande come lo era un tempo (quando alle conferenze all'estero gli italiani erano 4 o 5 su 1000 e più partecipanti). Interpreto questo fatto come un dato positivo in generale, che chiaramente toglie qualcosa al mercato italiano (in lingua italiana) per lo stesso genere di prodotto. Anche se io spero sempre che uno vada a una conferenza in Italia non solo perché il relatore parla in italiano, ma soprattutto perché è interessante quello che dice :-)
Vedremo se il TechEd europeo seguirà l'esempio americano in termini di numeri (io non ci andrò, ma sarà a Los Angeles in settembre per PDC 2005) e come andranno quest'anno le conferenze italiane a pagamento.
Nel frattempo, se qualcuno ha qualcosa da dire, i commenti sono aperti.
Il database mirroring di SQL Server 2005 è una delle tante importanti innovazioni di questo prodotto, che consentirà di avere due macchine fisicamente separate che hanno lo stesso identico database: i client si connettono a un server primario che propaga le transazioni al server secondario, in modo che alla fine i due database abbiano lo stesso contenuto.
Se si decide di avere un mirror completamente sincrono e pienamente transazionale con il master (la transazione andata a buon fine sul primario lo è sicuramente anche sul secondario) il prezzo da pagare è che il commit della transazione sul server primario è posticipato fino a che il server secondario non risponde positivamente (deve scrivere sul log delle transazioni). Come viene giustamente fatto notare in questo articolo, il problema è che in questa modalità il server secondario non può essere un hardware inferiore al primo (specialmente in termini di disco usato per il log delle transazioni), pena far decadere le prestazioni del server primario: come al solito è il punto più lento di un sistema a determinarne le prestazioni. Il pericolo è che non ci sia sensibilità su questo e molti comincino a montare come server secondario un PC obsoleto magari con uno storage capiente ma lento, giusto per avere un backup on-line... si può fare ma con una modalità di replica diversa da questo tipo di mirror.
Da subito negli Stati Uniti e tra poco (25 Aprile) anche in Europa, è possibile richiedere la Beta 2 di Visual Studio 2005 anche senza essere abbonati a MSDN.
Il link principale è questo, ma per l'Europa bisogna andare qui, dove al momento i distratti possono registrarsi per avere un reminder via mail.
Se avete un TabletPC non potete assolutamente perdervi il nuovo Experience Pack for TabletPC: tra le varie cose ci sono due applicazioni molto belle.
Una è Ink Art, che io non userò mai visto che sono negato al disegno ma se conoscete qualcuno con un po' di vena artistica... il Tablet si trasforma in una tavolozza per disegnare con acquarelli, matite e spray. Non si può spiegare quanto sia incredibile quello che si riesce a fare, bisogna provarlo.
L'altra è Ink Desktop, che consente di scrivere sul desktop del proprio PC come se fosse un foglio di carta. Forse non è molto utile nel quotidiano, ma è sicuramente carina da vedere.
Completano il quadro delle parole crociate (in inglese), un nuovo tema (Energy Blue, ma è solo estetica), uno Snipping Tool aggiornato e il Media Transfer, che io non uso (preferisco un impianto serio al PC) ma che molti troveranno comodo.
Ieri ho citato il post di Joe Duffy sulle linee guida per il rilascio di risorse in .NET (e quindi il pattern Dispose/Finalize). Leggendo interamente il post ho riflettuto (nuovamente) su quanto il C++/CLI sia un linguaggio estremamente comodo per lavorare in .NET. Per quanto riguarda il rilascio delle risorse, sicuramente meglio di C#.
Adesso il dubbio è: dopo essere riusciti a "convertire" un certo numero di sviluppatori VB6 a passare a C# invece che a VB.NET, riusciremo a portare qualcuno di loro al C++?
A parte la provocazione, sarebbe utile capire in un progetto reale quali siano pro e contro dell'uso di C++ in un team di sviluppatori C# che non hanno un background di provenienza C++. Potrebbe essere meno peggio di quanto uno potrebbe pensare...
Questo post di Joe Duffy sembra essere la guida definitiva (almeno fino a .NET 2.0) per la gestione delle risorse in .NET (e quindi per i pattern e l'uso di Dispose/Finalize).
Non ho molto da aggiungere, se non il fatto che la questione è oggettivamente complessa se la si esamina sin nei minimi dettagli. Risulta inevitabile che programmatori "inesperti" si scontrino con questo argomento nel modo peggiore (dopo aver scritto migliaia di righe di codice senza averci pensato). Non ho una soluzione a questo problema... le ricette semplici hanno poi sempre qualche effetto collaterale, temo.
Giovedì 5 maggio 2005 a Segrate c'è una giornata (gratuita) dedicata a Visual C++. Saranno presenti, direttamente da Redmond, i PM del prodotto: è un'ottima occasione per fare domande di qualsiasi genere, si ha di fronte qualcuno che la risposta deve averla per forza, al limite non può darla (per es. cosa ci sarà tra due versioni di Visual C++...). Purtroppo non riuscirò a essere presente, ma sarei sicuramente andato se non avessi avuto impegni lavorativi impossibili da spostare.
L'agenda è molto ampia e copre quattro versioni di Visual C++: dalla 6.0 fino alla 2005 (che uscirà entro l'anno) passando per le versioni 2002 e 2003: questo mi porta a suggerire a tutti quelli che ancora sviluppano con Visual C++ 6.0 di non mancare a questo evento, o in alternativa di studiare al più presto C++/CLI (saltando il Managed C++ delle versioni 1.x di .NET).
Rarissimamente mi è capitato di avere dei problemi nel debug di un'applicazione perché l'errore non era nel mio codice ma da qualche altra parte (librerie o sistema operativo - praticamente sempre colpa delle librerie). Due o tre volte sono incappato in bug del compilatore. Il bug del compilatore è una delle cose peggiori perché per individuarlo si spendono tantissime ore se non giorni.
Oggi ho notato (anche grazie a una mail) questo post di Raymond Chen che parla di problemi all'esecuzione di un programma dovuti a pratiche di overclocking del proprio PC. La cosa divertente è che pare ci siano utenti che hanno un PC in overclock senza nemmeno saperlo: il sospetto, è evidente, è che qualche venditore disonesto utilizzi CPU con clock inferiore per macchine con clock dichiarato superiore.... ma non è questa la cosa interessante del post.
Quello che mi ha colpito è che i problemi generati possono essere quasi aleatori, al punto da non generare il classico "schermo blu" che blocca il PC, ma modificando in modo subdolo e sottile l'esecuzione del codice macchina all'interno di un'applicazione. Dal punto di vista dello sviluppatore, un bug del genere è un incubo assoluto, anche se Raymond Chen spiega come il dump del processo consenta, vedendo i registri della CPU, di arrivare alla conclusione che si tratti di un problema hardware e non software. Certo sarebbe l'ultima cosa che uno potrebbe pensare di andare a vedere per un programma, che so, di contabilità scritto in VB6.
Personalmente non ho mai pensato di fare il benché minimo overclock di un PC che uso. Potrei giustificarlo solo per accelerare un videogame 3D (se va in crash, poco male... forse...) ma ho sempre pensato che il rapporto rischio/benefici non fosse allettante. Chissà se invece c'è qualche sviluppatore che "pompa" il PC all'estremo delle prestazioni...
Eric Sink ha pubblicato un bellissimo articolo in cui descrive quanto la conoscenza tecnica sia importante per prendere alcune decisioni, talvolta molto importanti se non addirittura strategiche per il futuro di un'azienda.
Quante volte abbiamo visto prendere delle decisioni senza la minima cognizione di causa di ciò che si stava facendo? In realtà le considerazioni di Eric sono applicabili anche in altri contesti, non strettamente tecnologici. Semplicemente, nel nostro settore le difficoltà e le conseguenze sono più esasperate.
Anticipo qualche possibile commento: "ma nella vita reale non conta solo l'ultima tecnologia disponibile". Certo, infatti non bisogna avere pregiudizi né in un senso né nell'altro. Inoltre, quello che conta in queste considerazioni è l'aspetto strategico, non il breve termine. Quante aziende ho visto (tanto da averci fatto l'abitudine) che navigano "a vista" senza avere un'idea di dove vogliono andare... Immagino sia un'esperienza comune a molti lettori, per questo i commenti sono aperti.
Da quasi un mese ho abbandonato SharpReader come RSS Aggregator. Non sarebbe una notizia se non che leggendo questo post di Raffaele Rialdi può essere interessante condividere la mia esperienza da utente.
Il mio attuale aggregator è Newz Crawler. Funziona bene, è veloce, occupa poca RAM (nonostante tutti i feed che seguo) e consente di aggregare insieme RSS e newsgroup (avete capito bene). Comodissimo. Ho riorganizzato gerarchicamente i feed e riesco a leggerli molto più velocemente (e soprattutto a dargli delle priorità).
Ha anche un sacco di feature, ma è secondario rispetto alla solidità che ha dimostrato in queste prime settimane.
Ha un solo difetto, che per me è un pregio: costa "ben" 25US$. Per me è un pregio perché significa che c'è qualcuno che lo mantiene più o meno costantemente. Non si può dire lo stesso di SharpReader (ultima versione è di 9 mesi fa...).
Note tecniche: Newz Crawler è scritto in Delphi, quindi anche se oggi non è in .NET potrà esserlo facilmente in futuro. Devo dire la verità: oggi è ancora difficile per un'applicazione .NET+Windows Forms rivaleggiare con Delphi in termini di prestazioni complessive su Windows (considerando che Delphi e le librerie VCL danno un ambiente di sviluppo assolutamente analogo a Visual Studio 2003, con la differenza che Delphi esiste da 10 anni, la 1.0 è uscita nel 1995). Ricordo che il papà di Delphi è Anders Hejlsberg, lo stesso di C# e delle WFC di J++. Ricordo anche che Windows Forms deriva da WFC che deriva da VCL (librerie di Delphi).
Nota etnica: Newz Crawler è scritto da un russo, Andrey Tumashinov. Delphi è molto usato in Russia e non è la prima volta che trovo software di qualità con la stessa provenienza (Delphi+Russia).
Non sapevo come intitolarlo questo post... Ralph Kimball è universalmente riconosciuto come uno dei principali "guru" del Data Warehouse e in particolare dell'approccio dimensionale che chi ha disegnato uno Star Schema conosce molto bene. Dunque è già per questo una persona degna del massimo rispetto.
Stamattina, leggendo questo articolo di Ralph Kimball segnalato da Donald Farmer in risposta a un mio post (in inglese) relativo a SSIS (se vi interessa l'argomento leggetelo insieme ai commenti, ne è nata una discussione molto interessante), ho intravisto nella biografia che Ralph è anche uno dei creatori di Xerox Star, il progetto di ricerca che Steve Jobs copiò per il Lisa (chi se lo ricorda, Lisa?) e poi per il Macintosh, che fu poi copiato da Microsoft in Windows. Insomma, la metafora di icone, cartelle e mouse... arriva da Xerox e lui faceva parte di quel team di sviluppo. Siccome sono scettico, ho controllato e ho trovato questo articolo di BYTE del 1982, "Designing the Star User Interface": tutto vero. Leggetevi l'articolo, ne vale la pena. Cito qualche perla:
- [...] a pointing device called the “mouse” [...]
- Every screen dot can be individually turned on or off by setting or resetting the corresponding bit in memory [per i troppo giovani: all'epoca i monitor erano soltanto a carattere ma c'erano ancora tante schede perforate]
- Questa fa capire i problemi nell'uso quotidiano del TabletPC: [The mouse] stays where it was left when you are not touching it. It doesn’t have to be picked up like a light pen or stylus.
- “What you see is what you get” (or WYSIWYG) refers to the situation in which the display screen portrays an accurate rendition of the printed page [questo è da nostalgia pura]
C'è molto altro ancora. Ma chi ha idea di cosa era l'informatica nel 1982 (io ho avuto il mio primo computer, un Sinclair ZX Spectrum, nel 1983) si renderà conto di quanto fosse visionaria un'idea simile.
Ora, tolto il salto nel passato, la morale di questo post (o per lo meno la mia conclusione) è che le persone brillanti restano tali anche quando fanno qualcosa di diverso. Senza voler fare paragoni storici che sarebbero comunque inappropriati, nel nostro "piccolo" mondo tecnologico una di queste persone si chiama Ralph Kimball.
La scorsa notte ho impiegato una buona mezz'ora a convincere un amico del fatto che la dimensione di un paging file, su un computer con molta RAM, deve essere minima.
So che ci sono milioni di documenti che sostengono il contrario, ma... la verità è scritta su Windows Internals (che è arrivato alla quarta versione, ma la stessa cosa c'era sulla prima versione molti anni fa, quando ancora il libro era scritto completamente da David Solomon). Per convincere il mio amico la mia parola e degli esperimenti perfettamente riproducibili non bastavano, quindi ecco qua il riferimento buono per tutti: pagine 445, 446 e 447 di Windows Internals 4th Edition.
Riassumo i punti salienti:
- La memoria virtuale disponibile in un sistema è data (sommariamente) da RAM fisica + Paging file
- Con un sistema che ha molta RAM (oggi vuol dire 2Gb o più) si può ragionevolmente lavorare senza paging file
- Per sapere di quanto paging file si ha bisogno, c'è questo metodo empirico: si usa la macchina per un po' (magari facendo tutte le operazioni più pesanti e aprendo tutti i programmi che uno potrebbe ragionevolmente aprire in maniera cocncorrente) e si vede dove arriva il "Commit Charge Peak" di Task Manager; tutto quello che avanza tra questo numero e il "Commit Charge Limit" è spazio di paging file che non è mai stato usato, qualora tale numero sia addirittura inferiore alla RAM fisica del sistema, il paging file non è mai stato necessario fino a quel momento.
Ora, se chiedete a un sistemista medio (e magari anche esperto) è probabile che vi risponderà: la dimensione ideale del paging file è una volta e mezza la RAM fisica del sistema. Semplicemente, non è vero. Questo valore di default risale a quando Windows NT viaggiava su macchine che mediamente avevano 64 o 128Mb di RAM. Ancora oggi lo si trova su migliaia di documenti e pure su moltissimi documenti Microsoft e MSDN.
Oggi siamo in uno scenario diverso e se su una macchina con 2Gb creo un paging file di 3Gb, devo sperare che non sia mai usato completamente perché avere paginato 3Gb significa avere prestazioni della macchina assolutamente scadenti (il processore, e probabilmente l'utente, passa il tempo ad aspettare che i dati siano caricati da disco). Purtroppo molti programmi non si curano di controllare se la memoria che richiedono al sistema operativo è memoria fisica o paginata e assumono (erroneamente) che mettere i dati in questa memoria sia sempre più veloce che accedere a un file su disco... Così invece di fare cache (nelle intenzioni del programmatore) si trovano a rallentare le operazioni. A questo punto meglio non far illudere un'applicazione di avere troppa memoria. Si potrebbe eliminare completamente il paging file, ma molte applicazioni non gestiscono abbastanza bene le condizioni di memoria insufficiente e allora meglio dare un minimo di paging file per consentire a qualche applicazione "avveduta" (tra queste SQL Server e Analysis Services, per fare un paio di esempi) di rilasciare un po' di memoria quando il sistema inizia a paginare. Ma se non c'è paging file, nessuno interviene per tempo. Comunque 100Mb sarebbero suffcienti per questo genere di necessità, con 500Mb si è già molto più che tranquilli.
Perché allora Microsoft non cambia il consiglio per il paging file? Semplicemente, per non rischiare qualche chiamata in più al supporto tecnico. Come ho detto, molte applicazioni gestiscono male condizioni di memoria limite, mentre se il sistema inizia a paginare l'utente percepisce il rallentamento e comincia a chiudere qualcosa prima che sia troppo tardi. In effetti, mettere un paging file più grande del necessario non ha quasi controindicazioni. Peccato però che tale file sia creato al momento dell'installazione di Windows e, se messo nel disco dove c'è anche il sistema operativo, va probabilmente a prendersi una delle parti "migliori" del disco (i dischi attuali sono più performanti nella parte iniziale del disco), relegando altre applicazioni più usate a zone meno veloci del disco stesso. Senza contare che avete X Gb di disco che magari non sono mai usati da nessuno (ma li avete pagati lo stesso).
La discussione (la notte scorsa) è nata perché mi si consigliava di prendere un disco dove alloggiare il paging file. Di tutti i modi che conosco per spendere soldi in hardware, mi sembrava uno dei peggiori, e così ho affrontato una difficile opera di convincimento (anche perché non ho avevo subito a portata di mano le pagine di Solomon/Russinovich che ho citato prima). A onor del vero esiste una sola condizione in cui è richiesta una dimensione minima specifica del paging file: se si vuole ottenere un dump completo della memoria in caso di blue screen (errore del sistema operativo che blocca tutto e forza al riavvio della macchina) allora il paging file deve avere una dimensione pari alla quantità di memoria fisica più qualcosetta (1Mb può bastare). Attivando il mini-dump questa esigenza viene meno. E non conosco molte persone che, una volta ottenuto un dump completo, sono in grado di farci qualcosa. Se non sviluppate driver, non mi sembra che sia un problema di cui dobbiate realmente preoccuparvi (con le dovute eccezioni: magari su alcuni server con alcune applicazioni molto particolari questi accorgimenti sono ritenuti indispensabili... ma nel 99% dei casi non è così).
Ora, siccome so che qualsiasi cosa io scriva qualcuno dirà che non ho ragione perché da qualche parte ha letto che esiste la formula magica (1,5 x RAM fisica, anche se esistono divertenti varianti a questa formula che portano il valore ideale a 2xRAM o a 2,5xRAM, ma senza che nessuno dia mai una minima spiegazione del perché di questi numeri), ho deciso di aprire i commenti a questo post e sentire le reazioni... probabilmente non sono stato abbastanza chiaro nello spiegare il perché di questo comportamento, ma la spiegazione non può prescindere dal comprendere il funzionamento del memory manager di Windows per quanto riguarda la memoria virtuale, argomento a cui da più di un anno ho promesso di dedicare un articolo che non trovo il tempo di scrivere. Comunque, se ci saranno domande mirate proverò a spiegare meglio i punti oscuri.
More Posts
Next page »