REAL Software Forums

The forum for REAL Studio and other REAL Software products.
[ REAL Software Website | Board Index ]
It is currently Sun Aug 01, 2010 12:08 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 1:16 pm 
Offline

Joined: Mon Jan 01, 2007 9:30 pm
Posts: 50
Re-raising an old thread.

Quote:
I can write slow, unusable code when I misuse the .NET APIs too. Most of the time it's not the tool that causes slow code, it's not understanding how to properly use the tool that causes slow code.


Aaron, This is extremely arrogant. RealBASIC DOES produce extremely slow applications when compared to other software.

I've just tried Steve's example above with RB2008r2. It takes over two minutes to scan a 3,000 item folder (on a USB hard drive). VB6 does this in 5.3 seconds.

I've seen you take the "use the win32api" approach a number of times. But that completely defeats the point of using RealBASIC.

If I want to use the win32 API for every operation I will code in C. I choose RealBASIC because of simplicity, rapid development, and cross platform compatibility.

In fact, using the API as indicated above will eliminate the cross platform bonus of RealBASIC completely, so I really don't understand why anybody would actually choose to use your software.

Please, fix RealBASIC. It's tragically slow. Or hire the monkeybread guy to fix your code and add some decent functionality.


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 2:34 pm 
Offline

Joined: Fri Dec 01, 2006 3:09 pm
Posts: 424
Location: Tennessee, USA
What about the step of setting the visible property of the Listbox to false before the start of the loop and back to true after the end of the loop. I have seen that help considerably in the speed improvement category.

One last thing, when writing code to traverse folders of the sort presented here one should always use TrueItem rather than Item so that aliases, and the windows equivalents are not resolved.


Top
 Profile E-mail  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 2:58 pm 
Offline
User avatar

Joined: Fri Sep 30, 2005 9:16 am
Posts: 734
Location: Boston, MA, USA
My Simple Cataloger app just blew through 8000+ files and folders and spit out a text file of every property within 9 seconds. I haven't changed the code in two years. I use no pragmas and no plug-ins. Just a dead-simple, carefully-crafted method.

Code:
Sub ListItems(theItem as FolderItem)
  dim mItemCount, thisItem as Integer
  dim thisLine as Integer
  dim currentItem as FolderItem
  mItemCount = theItem.count
  for thisItem = 1 to mItemCount
    if DataMgr.CO_01_ResolveAliases = true then //Resolve Aliases?
      currentItem = theItem.Item(thisItem)
    else
      currentItem = theItem.TrueItem(thisItem)
    end if
    if currentitem <> nil AND currentItem.exists = true then //a quick NilObjectException Check
      if currentItem.Directory = true then //check for recursion
        if SortFolderFile(currentItem) = true AND SortInvisible(currentItem) = true then
          CatalogItem(currentItem)
        end if
        if SortPackage(currentItem) = true then
          ListItems(currentItem)
        end if
      else
        if SortFolderFile(currentItem) = true AND SortInvisible(currentItem) = true then
          CatalogItem(currentItem)
        end if
      end if
    else
      DataMgr.UpdateStatusField(LanguageMgr.ErrorListItemsNilObjectExceptionCheck + currentItem.AbsolutePath)
    end if
  next
End Sub

Sub CatalogItem(theItem As FolderItem)
  //Default Data Points
  if DataMgr.CO_DP_Name = True then
    CO_DP_NameArray.Append theItem.Name
  end if
 
  if DataMgr.CO_DP_Path = True then
    CO_DP_PathArray.Append theItem.AbsolutePath
  end if
 
  if DataMgr.CO_DP_Size = True then
    CO_DP_SizeArray.Append theItem.Length //need to convert this to MB and GB when appropriate
  end if
 
  if DataMgr.CO_DP_CreatorCode = True then
    if theItem.MacCreator <> "" then
      CO_DP_CreatorCodeArray.Append theItem.MacCreator
    else
      CO_DP_CreatorCodeArray.Append "****"
    end if
  end if
 
  if DataMgr.CO_DP_TypeCode = True then
    if theItem.MacType <> "" then
      CO_DP_TypeCodeArray.Append theItem.MacType
    else
      CO_DP_TypeCodeArray.Append "****"
    end if
  end if
 
  //Other Data Points
  if DataMgr.CO_DP_Type = True then
    CO_DP_TypeArray.Append theItem.Type
  end if
 
  if DataMgr.CO_DP_CreationDate = True then
    CO_DP_CreationDateArray.Append theItem.CreationDate
  end if
 
  if DataMgr.CO_DP_ModificationDate = True then
    CO_DP_ModificationDateArray.Append theItem.ModificationDate
  end if
 
  if DataMgr.CO_DP_Locked = True then
    CO_DP_LockedArray.Append theItem.Locked
  end if
 
  if DataMgr.CO_DP_Visible = True then
    CO_DP_VisibleArray.Append theItem.Visible
  end if
 
  if DataMgr.CO_DP_DisplayedName = True then
    CO_DP_DisplayedNameArray.Append theItem.DisplayName
  end if
 
  if DataMgr.CO_DP_Owner = True then
    CO_DP_OwnerArray.Append theItem.Owner
  end if
 
  if DataMgr.CO_DP_Group = True then
    CO_DP_GroupArray.Append theItem.Group
  end if
 
  if DataMgr.CO_DP_Permissions = True then
    CO_DP_PermissionsArray.Append theItem.Permissions
  end if
 
  itemCount = itemCount + 1
 
End Sub


Anyone can write that nonsense (and the proof is in the number of file catalogers that exist already. I wrote it and sold it as an exercise for the real work I'm doing). I was a rank beginner when I wrote that, but I have yet to make it faster no matter what I do to it. My point is not to too my own horn but to make the point that usually it is the programmer that's the problem and not the language. What Aaron said isn't arrogant, it's an immutable law of programming that applies to all languages. RB isn't perfect but then neither are the rest of them.

_________________
What have you searched for so far? What have you tried so far?
RB2K9r5, Mac OS 10.6, Intel, Mac-centric development
Philip Regan - Oatmeal and Coffee - http://www.oatmealandcoffee.com
Treasurer - Association of REALBasic Professionals - http://www.arbp.org


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 3:49 pm 
Offline

Joined: Mon Jan 01, 2007 9:30 pm
Posts: 50
No, i'm sorry. Yes, often it is the programmer's fault that code ends up slow.

However..

Code:
sub recurse(fi as FolderItem)

  #if not DebugBuild then
    #pragma BackgroundTasks false
    #pragma BoundsChecking false
    #pragma NilObjectChecking false
    #pragma StackOverflowChecking false
  #endif

  Dim i As Integer
  Dim iMax As Integer = fi.Count
  Dim thisFile as FolderItem
  for i = 1 To iMax
  thisFile = fi.TrueItem( i )
  if thisFile.Directory Then // no need to test Boolean against True
    recurse(thisFile)
  else
   dim strFileName as string = thisFile.Name
   if right(strFileName,4)=".avi" then
    filelist.append strFileName
  end if
  end if
  next
end sub


The exact translation of this code runs over 500 times faster on visual basic six.

THAT is not a programmer fault.


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 3:56 pm 
Offline
User avatar

Joined: Fri Sep 30, 2005 9:16 am
Posts: 734
Location: Boston, MA, USA
Quote:
The exact translation of this code runs over 500 times faster on visual basic six.


<thinking_out_loud> There has to be something else going on elsewhere in the application that's causing the slow down. My method does more calculations that yours does yet yours takes longer. Mine is run from a thread if that makes any difference. Maybe take the
Code:
dim strFileName as string
out of the loop? </thinking_out_loud>

_________________
What have you searched for so far? What have you tried so far?
RB2K9r5, Mac OS 10.6, Intel, Mac-centric development
Philip Regan - Oatmeal and Coffee - http://www.oatmealandcoffee.com
Treasurer - Association of REALBasic Professionals - http://www.arbp.org


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 4:58 pm 
Offline

Joined: Fri Jan 06, 2006 3:21 pm
Posts: 8130
Location: Portland, OR USA
No, it's a documented fact that FolderItem.Item() and .TrueItem() can run significantly slower on Windows due to the constraints of the api, depending on how you use them. The underlying problem is that the windows api does not allow indexing of the directory entries. To reach item #100, you start at 1 and call Next 99 times. RB cannot predict how you are going to use the information, so it's forced to start fresh each time you call Item(). Add to that the fact that entries may be added and removed between calls to Item(), and RB has chosen the safest path.

RB *could* return an array of FolderItems, but that would be unnecessary bloat on the other platforms. Since there's a perfectly good api to iterate over the directory already available, it hasn't gotten much pressure. A feature request for

Function FolderItems.Items() as FolderItem()

would be a reasonable approach.

(I assume Philip's results are from the Mac, where the problem doesn't exist)

Tim


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 5:10 pm 
Offline
User avatar

Joined: Fri Sep 30, 2005 9:16 am
Posts: 734
Location: Boston, MA, USA
Quote:
(I assume Philip's results are from the Mac, where the problem doesn't exist)


Yes.

_________________
What have you searched for so far? What have you tried so far?
RB2K9r5, Mac OS 10.6, Intel, Mac-centric development
Philip Regan - Oatmeal and Coffee - http://www.oatmealandcoffee.com
Treasurer - Association of REALBasic Professionals - http://www.arbp.org


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 5:26 pm 
Offline

Joined: Fri Jan 06, 2006 3:21 pm
Posts: 8130
Location: Portland, OR USA
Quote:
Function FolderItems.Items() as FolderItem()

Aaron posted such a function on the forums recently. But thinking about it further, a function for NextItem and NextTrueItem would be even better. That would conform to the api better, and not require using up all the memory for an array of folderitems.

Remember, FolderItem began life on Mac, where the api is to use an index. When they ported to Windows, they used a mechanism that produced the same result, so code written on one platform would work on the other. Unfortunately, you pay a performance penalty on Windows, under certain conditions.

Whatever the solution, you're probably still going to end up with conditional code to do it one way on one platform and a different way on the other, so why not cut out the middle man and call the api directly? Your assertion that calling platform-specific code "defeats the point of using RealBasic" is complete rubbish.

Tim


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 6:17 pm 
Offline

Joined: Mon Jan 01, 2007 9:30 pm
Posts: 50
Quote:
so why not cut out the middle man and call the api directly?


Why not just code in C?

Why do people use RealBasic instead of a lower level language?

- Simple cross platform deployment
- Speed of development

I have already been forced to use the API in many instances where RealBASIC has fallen short; every API call I include makes it less and less beneficial to use RB.

That was, of course, until I bought the MBS plugin. The monkeybread plugin makes RealBASIC what it SHOULD be.

The MBS filelistmbs class is called in EXACTLY the same way, and is lightning fast (and, incidentally, it works perfectly on all platforms with virtuall no overhead). It really does just show you how badly coded RealBASIC is.

So, I have a choice between:

- Use the MBS plugin and deal with additional memory usage of my application
- Code this using API's for each platform, which will take a great deal of time, thereby nulling the reason I use RB


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 6:27 pm 
Offline

Joined: Fri Jan 06, 2006 3:21 pm
Posts: 8130
Location: Portland, OR USA
Quote:
every API call I include makes it less and less beneficial to use RB.

I'm sorry, but I don't understand that statement at all. And how is calling a declare using a "lower level language"? Declare is an RB keyword, isn't it?

To me, the ability to call a system API makes RB much, much more powerful.

Tim


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 6:55 pm 
Offline

Joined: Fri Sep 30, 2005 8:53 am
Posts: 810
timhare wrote:
Quote:
every API call I include makes it less and less beneficial to use RB.

I'm sorry, but I don't understand that statement at all. And how is calling a declare using a "lower level language"? Declare is an RB keyword, isn't it?

To me, the ability to call a system API makes RB much, much more powerful.


Yes I agree BUT but his point is you should not have to do it so OFTEN to great good performance and I agree with that too .....

If you have to find and learn the platform API's you will spend a heck of lot more time than just using the Xplatform RB framework ... so much so that you might be better off a platform specific product where you don't need to do that so often.

Yes you can work around RB's issues that way, but work arounds add complexity, coding time and code support issues.


- Karen


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 7:27 pm 
Offline

Joined: Sat Dec 24, 2005 8:18 pm
Posts: 5998
Location: Canada, Alberta, Near Red Deer
If you want to make a cross platform product that appears to be no different than any other then you really might need to delve into the declares on each platform
While RB can insulate you from some of that it won't cover 100% of it

_________________
My web site Great White Software
RBLibrary.com REALbasic learning


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Tue Jul 01, 2008 10:25 pm 
Offline

Joined: Wed Sep 28, 2005 6:06 pm
Posts: 274
Quote:
RealBASIC DOES produce extremely slow applications when compared to other software.

Your example demonstrates that one specific class in the REALbasic framework performs poorly at one specific task on one specific platform. If that is the only task you need to perform, then I suppose one could arrive at the generalization "extremely slow applications", but your specific case does not justify a general rule.

-Mars


Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Wed Jul 02, 2008 5:59 am 
Offline

Joined: Fri Sep 30, 2005 7:20 pm
Posts: 828
Oooh...I didn't know about the slowness of folderitems on Windows...great information.

I never used declares before and have little experience on a PC, is there an example of this Windows declare to bypass the folderitem.item in RB.

Oh...I used a shellscript
Code:
"dir /b /s"+" "+f.shellPath
in the past, but that was slow as well. I would split the result into an array and then use ubound to add each item to a listbox...but that was a few years back.


Kuzey

_________________
MY 3D Blog


Last edited by Kuzey on Wed Jul 02, 2008 6:56 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Real Basic - Produces Sluggish, Unusuable Code!
PostPosted: Wed Jul 02, 2008 6:46 am 
Offline
User avatar

Joined: Fri Sep 30, 2005 9:16 am
Posts: 734
Location: Boston, MA, USA
Quote:
If you want to make a cross platform product that appears to be no different than any other then you really might need to delve into the declares on each platform
While RB can insulate you from some of that it won't cover 100% of it


However, one could argue that the use of declares flies in the face of RB's "ease of use" paradigm. I'm no novice, but some functions I've looked at require a lot of surprisingly complex code. If you guys know what the API call is, you know how it works, you know it works better than what you have, and it's a function that's used by just about everyone, then what in the world are you waiting for? A bug report?

_________________
What have you searched for so far? What have you tried so far?
RB2K9r5, Mac OS 10.6, Intel, Mac-centric development
Philip Regan - Oatmeal and Coffee - http://www.oatmealandcoffee.com
Treasurer - Association of REALBasic Professionals - http://www.arbp.org


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 5 hours


Who is online

Users browsing this forum: Google [Bot], Paul Burnside and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group