Quelle est la nuance entre ces deux codes

moi j'en dis que les deux vallent la meme chose :)

Bonjour,
J'aimerais avoir votre avis sur la question suivante :
Les deux codes suivants font-ils la même chose ? Plus concretement, est
qu'au finish, on arrive au même point.

NUMERO 1
TempTable = new DataTable();
TempTable = new DataTable();

NUMERO 2
TempTable = new DataTable();
TempTable= null;
TempTable = new DataTable();

Mick wrote:

Les deux codes suivants font-ils la même chose ? Plus concretement,
est qu'au finish, on arrive au même point.

NUMERO 1
TempTable = new DataTable();
TempTable = new DataTable();

NUMERO 2
TempTable = new DataTable();
TempTable= null;
TempTable = new DataTable();

Bonjour,

Si l'on considère uniquement le code linéaire que vous présentez, il n'y
a sémantiquement aucune différence et l'affectation de null à TempTable
est, AMHA, inutile. La deuxième affectation écrase la référence
existante qui devient inaccessible et donc candidate à un futur garbage
collect.

Cependant, vous indiquez que cette opération se réalise dans une boucle
qui manipule la DataTable de manière plus complexe. Serait-il possible
de voir un code plus proche de ce que vous faites réellement?

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Une remarque cependant...

Quand vous n'affectez pas null, l'objet précédent ne peut pas être
inscrit comme candidat à la destruction par le GC car la variable n'est
pas sortie du scope. Il n'y a donc pas de moyen de décider de la
destruction de la DataTable précédente. La destruction effective de tous
les objets instanciés ne pourra être envisagée qu'en sortie de boucle.

Si vos DataTables sont gourmandes en mémoire et si le nombre de boucles
est important, vous asphyxiez donc votre application au bout de quelques
passes.

Donc si les 2 codes sont sémantiquement équivalents, la deuxième version
aide le GC à faire son travail plus efficacement et plus tôt.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Patrick Philippot wrote:

Si vos DataTables sont gourmandes en mémoire et si le nombre de
boucles est important, vous asphyxiez donc votre application au bout
de quelques passes.

Si ma remarque est correcte, un appel à TempTable.Clear (sans affecter
la valeur null à la variable) avant la nouvelle instanciation devrait
sinon faire disparaître le problème, du moins retarder son apparition
car la quantité de mémoire utilisée par la DataTable serait libérée
immédiatement au lieu d'attendre la destruction de l'objet.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Bonjour

Une remarque cependant...

Quand vous n'affectez pas null, l'objet précédent ne peut pas être
inscrit comme candidat à la destruction par le GC car la variable n'est
pas sortie du scope.

La variable existe encore, mais l'objet DataSet n'est plus référencé et
c'est ça qui compte. Si jamais le GC se déclenchait alors que la variable
existe, il se rendrait compte que l'objet DataSet peut être détruit.

--

Zazar

>> Si vos DataTables sont gourmandes en mémoire et si le nombre de
boucles est important, vous asphyxiez donc votre application au bout
de quelques passes.

Si ma remarque est correcte, un appel à TempTable.Clear (sans affecter
la valeur null à la variable) avant la nouvelle instanciation devrait
sinon faire disparaître le problème, du moins retarder son apparition
car la quantité de mémoire utilisée par la DataTable serait libérée
immédiatement au lieu d'attendre la destruction de l'objet.

Elle serait "libérable", mais pas forcément libérée immédiatement. Par
contre cette façon de procéder a l'avantage d'éviter de créer un nouvel
objet à chaque boucle.

--

Zazar

Bonjour,

J'aimerais avoir votre avis sur la question suivante :
Les deux codes suivants font-ils la même chose ? Plus concretement, est
qu'au finish, on arrive au même point.

NUMERO 1
TempTable = new DataTable();
TempTable = new DataTable();

NUMERO 2
TempTable = new DataTable();
TempTable= null;
TempTable = new DataTable();

Sous réserve que TempTable soit une variable locale de type DataTable, alors
ces 2 codes sont identiques. Aprés il se peut que vous ayez donné une
version trop réduite de votre code, et caché une information.

--

Zazar

Zazar wrote:

La variable existe encore, mais l'objet DataSet n'est plus référencé
et c'est ça qui compte.

Je suis d'accord. En théorie, c'est le comportement que j'attends mais
visiblement, la réalité semble être différente vu ce que rapporte Alex.

Je viens de tomber là-dessus, ce qui va dans le sens de ce que disais:

http://weblogs.asp.net/pwilson/archive/2004/02/20/77422.aspx

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Voici un bout du code, Concretement voila ce qu'il se passe.
Dans la variable TempStockGroup, j'ai une liste d'indice dont je recherche
la valeur au sein des bases de données BloomBerg.
Comme je remonte dans le temps au fur et à mesure que je trouve les valeurs,
la liste des indices diminue jusqu'à extinction ( la boucle dont je vous
parlais)
Voici maintenant le code.

foreach(Quote CurrentQuote in TempStockGroup2.Collection)
{
Tickers2[x]= CurrentQuote.Symbol;
x++;
}

//LA JE REINSTANTIE MA DATATABLE
TempTable= new System.Data.DataTable("Temp");
Log.TxtLog("Tentative de récupération du LastYear1 n°" + Trial + "
Date recherchée: " + LastYear + " - Nb Indices restants: " +
TempStockGroup2.Collection.Count);
try
{
//LA C LA PROCEDURE QUI FREEZE
TempTable BBObj.GetSeveralHistoricalDataFromSeveralSecurity(Tickers2,Fields,LastYear,L
astYear);
}
catch
{
Log.TxtLog("Problème de timeout BloomBerg !");

}
Log.TxtLog("Succès de connexion au serveur BloomBerg pour la
récupération des LastYear 1");

//Setting Quotes values
foreach(StockGroup CurrentGroup in QuotesSerialisation.Collection)
{
foreach(Quote CurrentQuote in CurrentGroup.Collection)
{
if(CurrentQuote.Type=="Indice" && CurrentQuote.IsAuto==true)
{

if(CurrentQuote.Symbol != "")
{
object[]findThisQuote = new object[1];
findThisQuote[0]= CurrentQuote.Symbol;
System.Data.DataRow DRow = TempTable.Rows.Find(findThisQuote);
if(DRow != null)
{
//LastYear
CurrentQuote.LastYear System.Convert.ToDouble(DRow["LAST_PRICE"]);
if(CurrentQuote.LastPrice != BBObj.FailureValue)

CurrentQuote.DifferenceLastPriceLastYear=((CurrentQuote.LastPrice /
CurrentQuote.LastYear)-1)*100;
if(CurrentQuote.LastYear != CurrentQuote.DefaultValue &&
CurrentQuote.LastYear !»Obj.FailureValue)
//LA JE RETIRE LES INDICES DONT J AI RECUPERE LES VALEURS
TempStockGroup2.RemoveQuote(CurrentQuote.Id);
}
}
}
}
}
//ET LA; C LA LIGNE DE COMMANDE QUI EMPECHE LE FREEZE.
TempTable = null;

**********************************
Et dans la faq Bloomberg (en Vb), il y a ceci :

When performing synchronous data requests to Bloomberg, the Results
parameter needs to be re-initialized after every call if the Subscribe or
GetHistorical method is called consecutively or in a loop. If you are
programming with Microsoft Visual Basic, for example, you could use the
vbEmpty keyword or you could use the Erase function. Here is how the code
might look:

Dim vtResult as Variant

For nLoop = 1 To 10
Blpdata1.Subscribe SecurityList, Cookie, Fields, Results:= vtResult
' ----------------------------
' PROCESS DATA
' ----------------------------
vtResult = vbEmpty
Next nLoop*************************************

"Zazar" <DILAVNI.nicolas.prats@iie.cnam.fr.INVALID> a écrit dans le message
de news:OEAY1Cw$EHA.824@TK2MSFTNGP11.phx.gbl...

Bonjour,


> J'aimerais avoir votre avis sur la question suivante :
> Les deux codes suivants font-ils la même chose ? Plus concretement, est
> qu'au finish, on arrive au même point.
>
> NUMERO 1
> TempTable = new DataTable();
> TempTable = new DataTable();
>
> NUMERO 2
> TempTable = new DataTable();
> TempTable= null;
> TempTable = new DataTable();


Sous réserve que TempTable soit une variable locale de type DataTable,

alors

ces 2 codes sont identiques. Aprés il se peut que vous ayez donné une
version trop réduite de votre code, et caché une information.

--

Zazar

Mick wrote:

//LA JE REINSTANTIE MA DATATABLE
TempTable= new System.Data.DataTable("Temp");
Log.TxtLog("Tentative de récupération du LastYear1 n°" +
Trial + " Date recherchée: " + LastYear + " - Nb Indices restants: " +
TempStockGroup2.Collection.Count);
try
{
//LA C LA PROCEDURE QUI FREEZE
TempTable > BBObj.GetSeveralHistoricalDataFromSeveralSecurity(Tickers2,Fields,LastYear,L
astYear);
}

Je ne comprends pas: pourquoi faire un tempTable = new DatatTable alors
que visiblement la méthode
BBObj.GetSeveralHistoricalDataFromSeveralSecurity retourne une référence
sur une DataTable qu'elle aura instancié elle-même?

Pas logique.

Pourrait-on voir la doc de cette méthode?

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr