I am thinking about improving the performance of IO, I don't completely understand the IO structure and I would like some help from the developers here.
I think if all fields are read when the first command to get ID and class is executed and stored in Object store and then RetrieveObject gets objects from ObjectStore it might give some performance improvement. Does this make sense?
Regards
Sandeep
It would be a question to ask to http://www.instantobjects.org/#newsgroups or to IO authors directly.
You have some structure diagrams at http://www.instantobjects.org/diagrams.html
The included IOHelp.chm file has a lot of useful information.
IO has no official release since 2006. But the SVN version at sourceforge has support for Delphi 2010. I suggest you get this updated version first.
About performance Improvement, did you use the StartTransaction/CommitTransaction methods of your TInstantConnector instance? It could have a big performance improvement in writing.
About reading, I didn't find any caching mechanism of data in the source code (after a quick review - but I could have missed something). But there is a statement cache included, which is not enabled by default. See the Statement_Cache.txt file in the Docs
You could take a look at other ORM frameworks for Delphi, you've a list at ORM for DELPHI win32
I should of course recommend ours: http://synopse.info/forum/viewforum.php?id=2 which has caching of both statements and data implement. :)
Related
I know a lot of questions have been asked about VB6 migration (and I've read most of them), but I'm still not entirely certain on what the best way to go about this is.
We have a client that we built an order tracking application for about a decade back and they came to us this week saying they were having some issues with it. The app was written entirely in VB6, which has been something of a hassle as tracking down the necessary tools to work with a project so old took some considerable effort. In an effort to make any future maintenance less of a headache, my boss wants to pitch the idea to them of updating the app to .net and wants to know what exactly that would entail. I've never done anything like this before, but what I've read (both here and elsewhere) suggests that Microsoft's "auto-update" from VB6 to .net simply doesn't work very well and I'd pretty much have to rebuild the app from the ground up.
To get to the crux of my question: is this the case? Would I pretty much just need to rewrite it, or is there another means of going about this that could/would save me a lot of time/effort?
Any insight would be greatly appreciated.
VB6 and VB.NET are radically different. The syntax has changed, and so has the underlying structures, forms, custom controls, and almost every single aspect you can possibly think about.
A complete redesign and reassessment of needs and functionality is imperative. With .NET the plethora of new libraries and features supersede the antiquated VB6 libraries, OCXs, etc. Also if you feel bold, you can migrate your code to C# and other CIL languages aside from VB.
Out of hand, the Microsoft migration tool will not do much. Moreover, it also depends on whether you have your business logic well separated from your GUI. Otherwise, it will make it even harder. Depending on the size of your application, it might make it quite expensive. Another possible solution you might consider is to run your app in a virtual environment or on a remote app http://technet.microsoft.com/en-us/library/cc730673(v=ws.10).aspx that will ease the deployment pain.
I have also researched this topic.
Try the smart rewrite solution that converts 95% of the code automatically.
first, run your app through the assessment wizard to determine estimated costs and resources needed.
http://visualwebgui.com/Gizmox/Solutions/InstantbCloudmoveb/tabid/744/Default.aspx
I've been browsing the DeHL repository on GoogleCode, and it looks really good to me.
Many interesting features that make basic programming tasks easier; Some neat things that are in the DotNet FCL, but are missing from the Delphi RTL can be found in this library;
Coded in a modern way, making good use of new language features;
Each class, record type, member function and parameter is documented in such a way that it'll show in the code completion of the Delphi IDE;
Well-organized and clean code;
Plenty of unit tests;
Open source and Free;
Basically, it looks like this library should've been included with Delphi, as part of the RTL.
One major drawback: The project has been discontinued. :-(
Now my question is:
Would it be safe to rely on this library for future projects, and use it as a base framework to build upon?
Basically I'd like to hear from somebody who's actually used this library whether or not it's worth it to invest time in getting to know this library, and why.
IIRC the project was discontinued because it was an over-engineered first attempt and a lot of its features turned out really messy and bloated. You should look at Alex Ciobanu's second attempt, which is simply called Collections. It contains most of the interesting features from DeHL, but leaner.
Be careful, though. It still makes heavy use of generics, which will make your binary size really big if you use it a lot, because the compiler team hasn't implemented a way to collapse duplicate code yet.
What should I know about code obfuscation in Delphi?
Should I or shouldn't I do it?
How it is done and is there any good tools (commercial/free) to automate it?
Why would you need to?
As a whole Delphi does not decompile back, unlike .net, so, while decompilation is always a bit of a risk, Ive never found a decompiler that actually did it to a useful way, lots of areas got left as assembler and so on.
If people want to rework your work, they can, no matter what, obfuscation or not, heck, some coders write almost naturally obfuscated code (having worked with a few)
My vote therefore, is shouldnt bother. Unless someone can show me a decompiler for delphi that really works, and produces full sets of compilable, and all delphi where it was originally, I wouldnt worry one drop.
Pythia is a program that can obfuscate binaries (not the source) created with Delphi or C++ Builder. Source code for Pythia is here.
Before:
After:
There's no point obfuscating since the compiler already does that for you.
There is no way to re-create the source code from the binary.
And components can be distributed in a useful way without having to distribute the source code.
So there usually is no (technical) reason for distributing the source code.
You could do other things to reduce an attacker's ability to disable your software activation system, for example, but in a native-compiled system like Delphi, you can't recreate source code from the binaries. Another answer (the accepted one at the moment) says exactly this, and someone else pointed out a helpful tool to obfuscate the RTTI information that people might use to gain some insight into the internals of your software.
You could investigate the following hardening techniques to block modification of your system, if that's what you really want:
Self-modifying code, with gating logic that divides critical functions of your code such as software activation, into various levels of inter-operable checksums, and code damage and repair.
Debug detection. You can detect debuggers being used on your software and attempt to block the software from working in this case.
Encrypt the PE binary data on disk, and decrypt it either at load time, or just in time before it runs, so that critical assembler code can not be so easily reverse engineered back to assembly language.
As others have stated, hackers working on your software do not need to restore the original sources to modify it. They will attempt, if they try it at all, to modify your binaries directly, and will use a detailed and expansive knowledge of assembler language to circumvent things you may wish them not to.
You can use free JCF (Jedi Code Formatter) to obfuscate your source code. However, pascal syntax does not allow strong obfuscation and JCF even doesn't do it's best (well, it's a code formatting tool, not obfuscator!)
I am new in the FIX and have requirement to develop a small FIX engine to communicate trading system. As I know there are plenty of FIX engine available but here requirement is to develop it.
Could anyone provide me the reference on any open source or any good article to start it?
For C++ use quickfix
Java use QuickfixJ
For .NET use VersaFix
To refer to Fix message constructions.
Both the libraries(Quickfix) have the same nomenclature as mentioned in the FIX protocol standards. But they are little buggy here and there, but you can rectify them in your source code. I have used both of the libraries in a commercial project and say so after seeing the libraries work. But the code is quite simple and they have an online reference manual to work with.
But developing your own library will be a big task for only one developer, if you have a team it can be much easier. Remember other than parsing you have to incorporate network communications, configuration on how to run it and threading structures also.
Developing your own FIX engine is not easy, specially if you will be dealing with FIX session level details yourself. Synchronizing sequences through ResendRequest, GapFill and SequenceReset is not easy and it would be nice if you can just use a FIX engine that is already doing that for you.
Another problem with the FIX protocol is REPEATING GROUPS. It is not easy to parse them quickly as it requires recursion or alternatively a complex iterative implementation.
Moreover, most Java FIX engines produce a lot of garbage when they are parsing the message, which increases variance and latency due to GC overhead.
Lastly, an intuitive API design is crucial to accelerate FIX development. If you want a good example of a clean API, you can check CoralFIX.
Disclaimer: I am one of the developers of CoralFIX.
You certainly want to look at QuickFix.
I am re-writing and/or consolidating a bunch of my "app framework" classes (basic mainform, about box, locking routines & purchase linking, auto-update, datamodule initializer, etc) -- Basically, I have a number of small potential shareware apps that I'm wanting to get out the door, and want to re-use code where I can, as well as build a framework for later apps to save time.
In one app I have auto-updating, I'm using LMD's WebUpdate, and am reasonably happy with it, but given that I'm re-vamping everything, I thought I'd see what the consensus is for "best approach" on this. I don't mind paying for commercial, nor using open source if that's best... just would rather not reinvent the wheel. (I've read: Delphi: How do you auto-update your applications?)
What is the best Auto-update component for Delphi Win 32 apps?
I use TmxWebUpdate. It's free, simple and easy to customize. I also own TMS Component Pack with TWebUpdate, but never really found a good incentive to switch.
I use TWebUpdate from TMS Components and am very happy with it. I haven't used LMD so unfortunately am not able to provide a comparison.
TMS also supply a whole raft of other components so if your re-writes require any else, especially if you want some shiny UI enhancements (TMS have a range of iPhone-style components) then the website is certainly worth a visit.
They seem fairly active in their support forums (although I haven't had need to use them for the WebUpdate component) and they have a fairly regular release cycle.
I have heard good compliment about TWebUpdate from Tmssoftware
also torry has much components for the same job, some are free and others are commericals.
Now what's the best?, it's depend on your needs, you already using one from LMD, which is a good company and I have very good experince with their components, but never used this one.
If you need a specific functionality, or you have some problems with the current one you are using, it's will be better to list them, so you will get a better answers, but it's hard to define the best, because every one has different experience and views.
I use TWebUpdate myself. It works, but the docs are a bit limited and it seems a bit buggy sometimes.
I have looked into LMD's (I have their full component pack), but it seemed to be much more limited than TWebupdate.
I'm also using TWebUpdate, and have to echo stg's comments on quality of support (good), and quality of documentation (spotty -- it's old, and doesn't always reflect their new features immediately).
You'll also find some places that stress the "roll your own" approach.
Remember that part of the auto-update issue is the tools that you will need to create the update "package" at your end. TMS Software makes a tool available for use with TWebUpdate, and it's reasonably well done. In my case, I'm "misusing" the component to deal with multiple files so that I can refresh additional related libraries, text files, etc. The update builder tool isn't really good for that. So there's some manual editing. But the updating part works well.
I'll also add a caution that you need to be careful with updates in Vista (and probably Windows 7). Writing to the protected places in the Program Files hierarchy was problematic for me. You may want to check that out with whatever component you use.
Have you considered Appwave from Embarcadero. It's not free and I don't know the price.